lxc container can power-off host machine

[maxadamo]

Binary package hint: lxc

Bug related information:
# lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04
# apt-cache policy lxc
lxc:
  Installed: 0.7.2-1~10.04~csz1
  Candidate: 0.7.2-1~10.04~csz1
  Version table:
 *** 0.7.2-1~10.04~csz1 0
        500 http://ppa.launchpad.net/cszikszoy/ppa/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status
     0.6.5-1 0
        500 http://mirror.switch.ch/ftp/mirror/ubuntu/ lucid/universe Packages

(NEVERMIND if I am using a PPA version: it's the same version you're using in Maverick and I don't think this is causing the issue that I am facing now).

I created a system image by using the tool "lxc-create" and by using the included templates (I even created images myself without this tool, and nothing changes with this issue)
The tool makes all the necessary steps to create the image (debootstrap and so on) and, at the end of the process, it creates a config file suitable for that image.
One of the last rows of the config file is:
lxc.mount.entry=proc /lxc/cont_1/rootfs/proc proc nodev,noexec,nosuid 0 0
same identical problem happens if I comment out this row and I mount /proc myself from /etc/fstab inside the container

The problem arises when I issue the command:
echo b > /proc/sysrq-trigger
In this case the host machine will power-off, and not the container.

It's possible to check what I said, without harming your server, just by running a sync command on the container:
echo s > /proc/sysrq-trigger
and than checking /var/log/messages on the host server. You'll see that the command is intercepted from the host and not from the container.

Right now, I have no idea how to circumvent this issue, and if this problem persist, I feel the security of LXC is heavily compromised.

[Kees Cook (kees)]

The problem is that there is no good /proc isolation yet. :(

[Serge Hallyn (serge-hallyn)]

Thanks for taking an interest and reporting this bug.

You can use LSMs to mitigate this to some extent. However the real solution will be completion of the user namespace and proc filtering. Both are well-known and substantial todo items.

I am marking this Triaged as (a) the proper solution is known, and (b) the community is slowly but surely addressing it.

[Serge Hallyn (serge-hallyn)]

This is partially solved by the new apparmor policy, and will be Closed once the new apparmor mount restrictions are available and exploited in the lxc apparmor policy (soon).

[Launchpad Janitor (janitor)]

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

---------------
lxc (0.7.5-3ubuntu41) precise; urgency=low

  * add lxc-shutdown command:
    - 0060-lxc-shutdown: add the command to the source
    - debian/lxc.upstart: use lxc-shutdown to shut down containers cleanly
    - debian/lxc.default: add LXC_SHUTDOWN_TIMEOUT (default 120s)
  * support per-container apparmor policies: (LP: #953453)
    - 0061-lxc-start-apparmor: add lxc.aa_profile to config file. If not
      specified, lxc-default profile is used for container. Otherwise, the
      specified profile is used.
      Note that per-container profiles must be named 'lxc-*'.
    - split debian/lxc-default.apparmor from debian/lxc.apparmor.
    - have /etc/apparmor.d/lxc-containers #include /etc/apparmor.d/lxc/*
    - debian/lxc.postinst: load the new lxc-containers profiles
    - debian/lxc.postrm: remove lxc-containers profiles
    - debian/rules: make new etc/apparmor.d/lxc dir and copy lxc-default into it
    - debian/control: add libapparmor-dev to build-depends
    - debian/lxc.upstart: load apparmor per-container policies at pre-start.
  * debian/lxc.apparmor: insert the stricter mount rules for lxc-start
    (LP: #645625) (LP: #942934)
  * debian/local/lxc-start-ephemeral: re-enable aufs option (LP: #960262)
  * replace upstream lxc-wait with our own bash script (LP: #951181)
    - debian/local/lxc-wait: the script
    - debian/rules: copy the script into place
  * 0062-templates-relative-paths: update templates to use relative paths,
    and make lxc-start always accept /var/lib/lxc/CN/rootfs as target prefix,
    to make lvm containers work. (LP: #960860)
 -- Serge Hallyn <email address hidden> Wed, 21 Mar 2012 08:20:06 -0500

[maxadamo (massimilianoadamo)]

don't want to argue, but may I ask why you decided to tag the urgency of this issue as "low"?
One can stop 30 containers and the host machine and the host machine, by issuing a simple command on one of the containers and you say urgency is just "low"? Wasn't it at least "medium", if not "high"?
cheers.

[Serge Hallyn (serge-hallyn)]

Quoting maxadamo (<email address hidden>):
> don't want to argue, but may I ask why you decided to tag the urgency of this issue as "low"?

Because of the many ways that root in a container can mess with a host,
this is only one.

> One can stop 30 containers and the host machine and the host machine, by
> issuing a simple command on one of the containers and you say urgency is just
> "low"? Wasn't it at least "medium", if not "high"?

No, because for 12.04 our goal is only to prevent accidental abuses of
the host by a container. There is no way we can claim to prevent
actual mischief.

Put another way, if this would be a high priority item for your use
case, then lxc is not yet right for your use case. Note that work
toward a user namespace, which will help achieve that goal, is heavily
under way.

Nevertheless, note that it is fix released. With the current apparmor
policy in 12.04, you should not be able to reboot through
/proc/sysrq-trigger.

[maxadamo (massimilianoadamo)]

It's correct what you wrote.
Thanks.

[Lawrance (jing)]

can somebody show we how to solve this problem with appamor, i install openstack with lxc installed, and i can use "echo b > /proc/sysrq-trigger" to power-off host.
sorry,i'am newbie to appamor...
thanks

[Serge Hallyn (serge-hallyn)]

Quoting Lawrance (<email address hidden>):
> can somebody show we how to solve this problem with appamor, i install openstack with lxc installed, and i can use "echo b > /proc/sysrq-trigger" to power-off host.
> sorry,i'am newbie to appamor...
> thanks

Openstack uses libvirt-lxc. The apparmor policies are in effect for
containers created and started through the lxc package, which is a
completely different source unfortunately. Adding apparmor protections
will need to either be done separately in libvirt source, or achieved by
writing a new libvirt lxc driver which uses our lxc package.

[Lawrance (jing)]

thanks for your infomation,Serge