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

[Daniel P. Berrange]

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 :|