setuid executables in a container may compromise security on the host

[Andrea Corbellini]

==================================
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.)

[Serge Hallyn (serge-hallyn)]

Thanks for pointing this out. I don't believe it would be a serious loss of functionality to chmod 0700 /var/lib/lxc. I also don't feel that this is a high priority bug since, so far, we do not recommend allowing unprivileged users to use containers. So I think a regular update in trusty with SRUs to all previous releases is ok.

[Andrea Corbellini (andrea.corbellini)]

> I also don't feel that this is a high priority bug since, so far, we do not recommend allowing unprivileged users to use containers.

Agreed. Especially because (currently) it's fairly easy to escape from LXC when you have root access to the container.

> I don't believe it would be a serious loss of functionality to chmod 0700 /var/lib/lxc.
> ...
> So I think a regular update in trusty with SRUs to all previous releases is ok.

I've used this functionality many times in the past. While I can do without it in exchange for security, some people may have written scripts that depend on this functionality, hence a SRU would be nasty for them.

My personal opinion is: LXC is insecure and it does not deserve potentially dangerous security updates in stable releases.

[Stéphane Graber (stgraber)]

For those users, getting back to the old way would be a chmod away and I asked Serge to make sure permissions would only be changed once and not with every update, so it should be a one time thing.

As for security, while we don't currently say LXC is secure on Ubuntu, we're not aware of any way to escape a default container (Ubuntu on Ubuntu) starting with 12.04 when running with all default settings (specifically, under apparmor). If you know of a way to do so, I'd love to hear about it so we can adapt our apparmor profile to prevent it.

[Andrea Corbellini (andrea.corbellini)]

Hi Stéphane,

I can see at least three ways of escaping.

The first is using LXC through libvirt. I see that there's an Apparmor profile for usr.bin.lxc-start, but AFAIK libvirt does not use lxc-start. Also, libvirt does not load the "lxc-containers" profile (AFAIK).

This is proven by the fact that `cat /sys/kernel/security/apparmor/profiles` does not fail when done from within my LXC+libvirt guest.

Also, reading /etc/apparmor.d/abstractions/lxc/container-base I see that there are many deny rules, but you are missing at least two: /sys/kernel/uevent_helper and /sys/class/mem/null/uevent. See http://blog.bofh.it/debian/id_413 for a way for escaping using these two files.

Finally, while there are rules that deny read and writes to /sys, but there are no rules that deny me to e.g. `mount -t sysfs sysfs /tmp/sys` or bind-mount /sys to an another location. (I'm not sure about this point because, you know, I'm using libvirt and I cannot test.)

[Stéphane Graber (stgraber)]

Right, libvirt-lxc isn't LXC (even though they sort of stole the name) and is indeed completely unsafe...

As for the rest, I'm happy to report that you misread the apparmor profile and that we thought of and blocked all of those from the beginning as is shown below:
root@lxc-dev:/# echo abc > /sys/kernel/uevent_helper
bash: /sys/kernel/uevent_helper: Permission denied

root@lxc-dev:/# echo abc > /sys/class/mem/null/uevent
bash: /sys/class/mem/null/uevent: Permission denied

root@lxc-dev:/# mount -t sysfs syfs /mnt
mount: block device syfs is write-protected, mounting read-only
mount: cannot mount block device syfs read-only

root@lxc-dev:/# mount --bind /sys /mnt
mount: block device /sys is write-protected, mounting read-only
mount: cannot mount block device /sys read-only

[Andrea Corbellini (andrea.corbellini)]

Good news.

However I must say that the documentation on LXC does not say that libvirt is less secure than the official LXC: https://help.ubuntu.com/13.10/serverguide/lxc.html#lxc-libvirt

So either libvirt should ship with an Apparmor profile for LXC, or a warning should be added to the relevant places of the documentation

[Launchpad Janitor (janitor)]

This bug was fixed in the package lxc - 1.0.0~alpha2-0ubuntu5

---------------
lxc (1.0.0~alpha2-0ubuntu5) trusty; urgency=low

  [ Serge Hallyn]
  * debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
    to be perms 700. That prevents unprivileged users from running setuid-root
    applications. Install that way by default, and for any previous versions,
    update the permissions. After this version, respect the user's choice.
    (LP: #1244635)

  [ Stéphane Graber ]
  * Allow lxc.conf to start even if LXC_AUTO=false so that other jobs
    can depend on it. Also make sure we always load our apparmor profiles.
    (LP: #1227937)
 -- Stephane Graber <email address hidden> Tue, 29 Oct 2013 12:15:21 -0400

[Stéphane Graber (stgraber)]

Hello Andrea, or anyone else affected,

Accepted lxc into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lxc/0.7.5-3ubuntu68 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Stéphane Graber (stgraber)]

Hello Andrea, or anyone else affected,

Accepted lxc into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lxc/0.9.0-0ubuntu3.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Seth Arnold (seth-arnold)]

Serge, what does " After this version, respect the user's choice." mean? Does this mean someone upgrading from e.g. 12.04.3 lxc packages to 14.04 lxc packages -- skipping this update -- would have the 'unsafe' permissions?

Or will this check be carried before to e.g. 14.04 lxc packages and only execute once, allowing an administrator to undo the change?

Thanks

[Serge Hallyn (serge-hallyn)]

Quoting Seth Arnold (<email address hidden>):
> Serge, what does " After this version, respect the user's choice." mean?

It means if the user manually chmods /var/lib/lxc to 755, we don't
change it again after this. (Except, see below)

> Does this mean someone upgrading from e.g. 12.04.3 lxc packages to 14.04
> lxc packages -- skipping this update -- would have the 'unsafe'
> permissions?
>
> Or will this check be carried before to e.g. 14.04 lxc packages and only
> execute once, allowing an administrator to undo the change?

The test for package version will be kept until at least after
14.04. Since the trusty lxc version checks for the
1.0.0~alpha2-0ubuntu5 versio, an lts-to-lts upgrade will get
this check. Which sort of belies my statement that user
choices will be respected.

[Stéphane Graber (stgraber)]

Not to mention the change is being SRUed to all release, so they'll get the change way before they dist-upgrade.

[Stéphane Graber (stgraber)]

Hello Andrea, or anyone else affected,

Accepted lxc into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lxc/0.7.5-3ubuntu69 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Stéphane Graber (stgraber)]

Hello Andrea, or anyone else affected,

Accepted lxc into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lxc/0.8.0~rc1-4ubuntu39.12.10.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Stéphane Graber (stgraber)]

Hello Andrea, or anyone else affected,

Accepted lxc into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lxc/0.8.0~rc1-4ubuntu39.12.10.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Andrea Corbellini (andrea.corbellini)]

Waiting for the SRU to land in Saucy. Has it been delayed for some reason or has it been forgotten? :-)

[Serge Hallyn (serge-hallyn)]

The saucy fix must wait for another active SRU to complete.

[Stéphane Graber (stgraber)]

Hello Andrea, or anyone else affected,

Accepted lxc into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lxc/1.0.0~alpha1-0ubuntu13 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Stéphane Graber (stgraber)]

Confirmed on precise

[Stéphane Graber (stgraber)]

Confirmed on quantal

[Stéphane Graber (stgraber)]

Confirmed on raring

[Stéphane Graber (stgraber)]

And confirmed on saucy. Marking verification-done.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lxc - 0.7.5-3ubuntu69

---------------
lxc (0.7.5-3ubuntu69) precise-proposed; urgency=low

  * mkdir /var/{cache.lib}/lxc before chmoding them to avoid FTBFS.

lxc (0.7.5-3ubuntu68) precise-proposed; urgency=low

  * debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
    to be perms 700. That prevents unprivileged users from running setuid-root
    applications. Install that way by default, and for any previous versions,
    update the permissions. After this version, respect the user's choice.
    (LP: #1244635)
  * 0312-ubuntu-Improper-pty-permissions.patch: fix permissions with which
    devpts is mounted in containers. (LP: #1242913)
 -- Serge Hallyn <email address hidden> Tue, 29 Oct 2013 15:01:36 -0500

[Stéphane Graber (stgraber)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lxc - 0.8.0~rc1-4ubuntu39.12.10.5

---------------
lxc (0.8.0~rc1-4ubuntu39.12.10.5) quantal-proposed; urgency=low

  * add mkdir before chown of /var/{lib,cache}/lxc to avoid build failure.

lxc (0.8.0~rc1-4ubuntu39.12.10.4) quantal-proposed; urgency=low

  * debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
    to be perms 700. That prevents unprivileged users from running setuid-root
    applications. Install that way by default, and for any previous versions,
    update the permissions. After this version, respect the user's choice.
    (LP: #1244635)
  * 0312-ubuntu-Improper-pty-permissions.patch: fix permissions with which
    devpts is mounted in containers. (LP: #1242913)
 -- Serge Hallyn <email address hidden> Tue, 29 Oct 2013 23:17:06 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package lxc - 0.9.0-0ubuntu3.7

---------------
lxc (0.9.0-0ubuntu3.7) raring-proposed; urgency=low

  * debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
    to be perms 700. That prevents unprivileged users from running setuid-root
    applications. Install that way by default, and for any previous versions,
    update the permissions. After this version, respect the user's choice.
    (LP: #1244635)
  * 0112-ubuntu-Improper-pty-permissions.patch: fix permissions with which
    devpts is mounted in containers. (LP: #1242913)
 -- Serge Hallyn <email address hidden> Tue, 29 Oct 2013 13:45:17 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package lxc - 1.0.0~alpha1-0ubuntu13

---------------
lxc (1.0.0~alpha1-0ubuntu13) saucy-proposed; urgency=low

  * debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
    to be perms 700. That prevents unprivileged users from running setuid-root
    applications. Install that way by default, and for any previous versions,
    update the permissions. After this version, respect the user's choice.
    (LP: #1244635)
 -- Serge Hallyn <email address hidden> Mon, 04 Nov 2013 08:12:35 -0600