[libvirt-users] lxc capabilities
I'm experimenting with the libvirt lxc driver, and wondering if there is some way to control the capabilities assigned to the container processes. With lxc-tools, I can specify a configuration option, lxc.cap.drop, which causes the container processes to drop the specified privileges. My libvirt containers seem to run with cap_sys_module,cap_sys_boot,cap_sys_time,cap_audit_control,cap_mac_admin which is rather more permissive than I'd like. In particular, cap_sys_boot allows a container to reboot the host machine. I am running libvirt-0.9.2 from squeeze-backports on debian squeeze. Cheers, -C-
On Wed, Dec 07, 2011 at 12:55:44PM -0800, Chris Haumesser wrote:
I'm experimenting with the libvirt lxc driver, and wondering if there is some way to control the capabilities assigned to the container processes.
With lxc-tools, I can specify a configuration option, lxc.cap.drop, which causes the container processes to drop the specified privileges.
My libvirt containers seem to run with cap_sys_module,cap_sys_boot,cap_sys_time,cap_audit_control,cap_mac_admin which is rather more permissive than I'd like. In particular, cap_sys_boot allows a container to reboot the host machine.
I think you have that the wrong way around. The containers run *without* cap_sys_{module,boot,time,audit_control,mac_admin}. Any of the remaining capabilities we allow should be safe to use within the context of a container (well ok, we need the UID/GID namespace stuff to be finished really for this to be safe). But we certainly block clearly dangerous things like reboot & module loading Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Daniel P. Berrange wrote:
I think you have that the wrong way around. The containers run *without* cap_sys_{module,boot,time,audit_control,mac_admin}.
Am I misinterpreting the output of getpcaps then? (getpcaps is rather undocumented). See: http://pastebin.com/6FkXt66c Moreover, I opened a virsh console to my helloworld container, typed 'reboot' and the whole host machine rebooted. Yikes! Or are these bugs in the 0.9.2 codebase that have since been fixed? -C-
Chris Haumesser wrote:
Am I misinterpreting the output of getpcaps then? (getpcaps is rather undocumented).
Answering my own question, I was misinterpreting the output of getpcaps. I found the cap_from_text(3) man page, which explained the output format. I still don't understand why I was able to reboot the host from within a container, however. -C-
On Thu, Dec 08, 2011 at 07:14:41AM -0800, Chris Haumesser wrote:
Chris Haumesser wrote:
Am I misinterpreting the output of getpcaps then? (getpcaps is rather undocumented).
Answering my own question, I was misinterpreting the output of getpcaps. I found the cap_from_text(3) man page, which explained the output format.
I still don't understand why I was able to reboot the host from within a container, however.
Well I just confirmed (the hard way!) that you are correct. It is possible to reboot the host from inside the container, despire CAP_SYS_REBOOT being blocked. I'll try & figure out how that's happening/possible... Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Dec 08, 2011 at 03:34:48PM +0000, Daniel P. Berrange wrote:
On Thu, Dec 08, 2011 at 07:14:41AM -0800, Chris Haumesser wrote:
Chris Haumesser wrote:
Am I misinterpreting the output of getpcaps then? (getpcaps is rather undocumented).
Answering my own question, I was misinterpreting the output of getpcaps. I found the cap_from_text(3) man page, which explained the output format.
I still don't understand why I was able to reboot the host from within a container, however.
Well I just confirmed (the hard way!) that you are correct. It is possible to reboot the host from inside the container, despire CAP_SYS_REBOOT being blocked. I'll try & figure out how that's happening/possible...
It is obvious in retrospect. If you have a container which is sharing the host OS's root filesystem, then it can see the host's /dev which contains a /dev/initctrl FIFO pipe. The 'reboot' command can tell the host OS to shutdown via that pipe, thus lack of CAP_SYS_REBOOT is irrelevant. Since this is a FIFO and not a blockdev/chardev we can't use cgroups to prevent access to /dev/initctrl. The only reliable way is to wait for the kernel's user namespace stuff. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
Chris Haumesser -
Daniel P. Berrange