Bug Description
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://
100 /var/lib/
0.6.5-1 0
500 http://
(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.
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.
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.
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).
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_
* support per-container apparmor policies: (LP: #953453)
- 0061-lxc-
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/
- have /etc/apparmor.
- debian/
- 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/
(LP: #645625) (LP: #942934)
* debian/
* replace upstream lxc-wait with our own bash script (LP: #951181)
- debian/
- debian/rules: copy the script into place
* 0062-templates-
and make lxc-start always accept /var/lib/
to make lvm containers work. (LP: #960860)
-- Serge Hallyn <email address hidden> Wed, 21 Mar 2012 08:20:06 -0500
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.
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-
It's correct what you wrote.
Thanks.
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-
sorry,i'am newbie to appamor...
thanks
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-
> 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.
thanks for your infomation,Serge
The problem is that there is no good /proc isolation yet. :(