2013-10-25 12:18:33 |
Andrea Corbellini |
bug |
|
|
added bug |
2013-10-25 21:12:01 |
Serge Hallyn |
lxc (Ubuntu): importance |
Undecided |
Medium |
|
2013-10-25 21:12:01 |
Serge Hallyn |
lxc (Ubuntu): status |
New |
Triaged |
|
2013-10-25 21:16:37 |
Serge Hallyn |
nominated for series |
|
Ubuntu Lucid |
|
2013-10-25 21:16:37 |
Serge Hallyn |
nominated for series |
|
Ubuntu Precise |
|
2013-10-25 21:16:37 |
Serge Hallyn |
bug task added |
|
lxc (Ubuntu Precise) |
|
2013-10-25 21:16:37 |
Serge Hallyn |
nominated for series |
|
Ubuntu Raring |
|
2013-10-25 21:16:37 |
Serge Hallyn |
bug task added |
|
lxc (Ubuntu Raring) |
|
2013-10-25 21:16:37 |
Serge Hallyn |
nominated for series |
|
Ubuntu Saucy |
|
2013-10-25 21:16:37 |
Serge Hallyn |
bug task added |
|
lxc (Ubuntu Saucy) |
|
2013-10-28 20:30:00 |
Serge Hallyn |
nominated for series |
|
Ubuntu Quantal |
|
2013-10-28 20:30:00 |
Serge Hallyn |
bug task added |
|
lxc (Ubuntu Quantal) |
|
2013-10-28 20:32:14 |
Serge Hallyn |
description |
If I execute "/var/lib/lxc/NAME/rootfs/usr/bin/sudo -i" on the host system, it works exactly like "/usr/bin/sudo -i".
Now suppose that a user that has root access to the LXC container creates a flawed setuid executable. What happens is that now the host system is flawed too.
For example, I can patch the container's sudo to skip the authentication checks and then use /var/lib/lxc/NAME/rootfs/usr/bin/sudo from the host to gain root privileges.
This assumes that you have both root access to the container and unprivileged access to the host. However the point is: insecure filesystem policies in a container may be source of security holes on the host system.
Of course, the same applies to capabilities too, not just the setuid/gid bits.
A possible solution to this problem would be to chmod 0700 the /var/lib/lxc directory. However doing so you lose the ability to browse files on the container from the host.
An alternative would be to tell Apparmor to deny the execution of every file contained in /var/lib/lxc. (Or at least, to deny the execution of setuid/gid/cap files, if that's possible.) |
==================================
1. Impact: unprivileged users could run setuid-root binaries from out-of-date containers.
2. Development fix: make /var/lib/lxc world- and group-unreadable
3. Stable fix: same as development fix
4. Test case:
sudo apt-get -y install lxc
sudo lxc-create -t ubuntu -n u1
ls /var/lib/lxc/u1/rootfs/bin/passwd
5. Regression potential: users who want to view container contents without being root, will now have to do so as root, or manually change the /var/lib/lxc permissions.
If I execute "/var/lib/lxc/NAME/rootfs/usr/bin/sudo -i" on the host system, it works exactly like "/usr/bin/sudo -i".
Now suppose that a user that has root access to the LXC container creates a flawed setuid executable. What happens is that now the host system is flawed too.
For example, I can patch the container's sudo to skip the authentication checks and then use /var/lib/lxc/NAME/rootfs/usr/bin/sudo from the host to gain root privileges.
This assumes that you have both root access to the container and unprivileged access to the host. However the point is: insecure filesystem policies in a container may be source of security holes on the host system.
Of course, the same applies to capabilities too, not just the setuid/gid bits.
A possible solution to this problem would be to chmod 0700 the /var/lib/lxc directory. However doing so you lose the ability to browse files on the container from the host.
An alternative would be to tell Apparmor to deny the execution of every file contained in /var/lib/lxc. (Or at least, to deny the execution of setuid/gid/cap files, if that's possible.) |
|
2013-10-29 17:15:00 |
Launchpad Janitor |
lxc (Ubuntu): status |
Triaged |
Fix Released |
|
2013-10-29 18:47:15 |
Stéphane Graber |
lxc (Ubuntu Precise): status |
New |
Fix Committed |
|
2013-10-29 18:47:19 |
Stéphane Graber |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2013-10-29 18:47:24 |
Stéphane Graber |
bug |
|
|
added subscriber SRU Verification |
2013-10-29 18:47:26 |
Stéphane Graber |
tags |
|
verification-needed |
|
2013-10-29 18:48:43 |
Serge Hallyn |
lxc (Ubuntu Quantal): status |
New |
Fix Committed |
|
2013-10-29 18:48:47 |
Serge Hallyn |
lxc (Ubuntu Raring): status |
New |
Fix Committed |
|
2013-10-29 18:48:49 |
Serge Hallyn |
lxc (Ubuntu Raring): importance |
Undecided |
Medium |
|
2013-10-29 18:48:53 |
Serge Hallyn |
lxc (Ubuntu Quantal): importance |
Undecided |
Medium |
|
2013-10-29 18:48:56 |
Serge Hallyn |
lxc (Ubuntu Precise): importance |
Undecided |
Medium |
|
2013-10-29 18:48:59 |
Serge Hallyn |
lxc (Ubuntu Saucy): importance |
Undecided |
Medium |
|
2013-11-05 03:14:58 |
Stéphane Graber |
lxc (Ubuntu Saucy): status |
New |
Fix Committed |
|
2013-11-05 16:10:45 |
Stéphane Graber |
tags |
verification-needed |
verification-done |
|
2013-11-05 16:13:42 |
Stéphane Graber |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2013-11-05 16:13:39 |
Launchpad Janitor |
lxc (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
2013-11-05 16:14:03 |
Launchpad Janitor |
lxc (Ubuntu Quantal): status |
Fix Committed |
Fix Released |
|
2013-11-05 16:14:24 |
Launchpad Janitor |
lxc (Ubuntu Raring): status |
Fix Committed |
Fix Released |
|
2013-11-12 11:40:33 |
Launchpad Janitor |
lxc (Ubuntu Saucy): status |
Fix Committed |
Fix Released |
|