[libvirt] [PATCH v3 0/5] RFC: grant KVM guests retain arbitrary capabilities

[Daniel P. Berrange]

On Fri, Jan 27, 2012 at 09:38:48AM +0100, Paolo Bonzini wrote:
> On 01/27/2012 08:18 AM, Taku Izumi wrote:
> >>  In any case adding rawio (which is a per-process capability) to a<disk>
> >>  element would be wrong.
> >
> >It is true that process capability affects not per disk but a domain.
> >It's a bit strange, but it is OK in my personal opinion.
> 
> No, this must be made very clear in the XML!  Remember that rawio
> lets you send dangerous commands such as WRITE BUFFER and any vendor
> specific thing.  I absolutely don't think it's okay to enable them
> on disks just because _another_ disk gets a rawio="yes" attribute.
> 
> If you want to add it to the <disk> element, you should first add
> support for an arbitrary whitelist in the kernel (e.g. by extending
> the devices cgroups).  The whitelisting code is in the kernel, just
> not the cgroups interface.

Yep, I tend to agree. We should have

  1. rawio="yes|nmo"  on the <disk> element somewhere
  2. Give the QEMU process CAP_SYS_RAWIO
  3. Use the devices cgroup to specify which individual disks
     can use rawio.

That said I don't think we need to block the entire patch, just waiting
for #3.  I think it is acceptable to implement #1 & #2 right now,
provided that we mark the domain as tainted. After all if we don't do
#1 & #2, then people are just going to set clear_emulator_capabilities=0
which is even more insecure.


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