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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list