Re: [libvirt] [PATCH v3 0/5] RFC: grant KVM guests retain arbitrary capabilities
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 :|