[libvirt] [PATCH 0/3] Control Linux capabilities in libvirt

The libvirtd system instance runs privileged (as root), and likewise so do VMs run from it. This is undesirable for obvious security reasons, even if you do have SELinux available. Linux has a concept of capabilities which are actually what gives 'root' its power. If you take away all capabilities from a process running root, you significantly limit its power. eg if you take away CAP_DAC_OVERRIDE, root can now only read files explicitly owned by root, not any other users. There are about 30-something capabilities at this time - see 'man 7 capabilities' for a full list and examples of what each allows you todo Historically it has needed alot of code to manage/modify capabilities, but there is a new library for managing Linux capabilities recently released, which makes their use significantly easier. This is known as libcap-ng http://people.redhat.com/sgrubb/libcap-ng/ I anticipate a several step process 1. Drop all capabilities from spawned processes which don't need it 2. Reduce capabilities from the libvirtd daemon 3. Run VM processes as non-root, unprivileged users 4. Run the libvirtd daemon as as a non-root, semi-privileged user This series of patches lays the very *basic* groundwork for controlling Linux capabilities, doing options 1 and 2. Option '3' is what I'd really like to get working, but it is more invasive, because it will need changes to the QEMU driver so it will chown disks to the 'kvm' user before spawning kvm (likewise for PCI devs, USB devs, etc). Step 1 is a mild security benefit, adding step 3 is a significant step forward. Step 2 doesn't have much tangible benefit, since our functionality requires that we need CAP_DAC_OVERRIDE, CAP_SYS_ADMIN and CAP_NET_ADMIN. Once you give a process those, its pretty much game over for security benefits of removing other capabilities. The 4th option *could* help security, but only if there are some changes to the way distros deploy apps. In particular they'd need to make sure binaries are installed with correct file capabilities, before we could use it, otherwise we wouldnt' be able to get child processes we spawn to keep capabilities they need. In addition, with step 4, we'd be asking admins to trade off functionality against security. eg, we could only drop CAP_DAC_OVERRIDE, if you turned off certain features. It is certainly desirable for users who want to tightly lock down their system, but not for a general purpose install. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|