Re: [Qemu-devel] live snapshot wiki updated

[Eric Blake]

[adding the libvir-list]

On 07/19/2011 08:09 AM, Jes Sorensen wrote:
> On 07/19/11 15:58, Eric Blake wrote:
> > On 07/19/2011 07:27 AM, Jes Sorensen wrote:
> > > Eric, what happens if libvirt in an selinux environment tells QEMU to
> > > launch using an image file that is backed by backing file(s)?
> >
> > Before starting qemu, libvirt first parses all the image files, to see
> > if any of them have backing images.  For every qcow2 or qed image with a
> > backing file, libvirt sets the SELinux context of both the qcow2 image
> > and its backing file so that qemu will be able to successfully open()
> > them.  But if any of those files reside on NFS, then it is not possible
> > to label individual files, so it requires setting the SELinux bool
> > virt_use_nfs, which thus gives qemu the power to open() arbitrary files
> > on NFS, and you've lost security.
>
> Urgh, libvirt parsing image files is really unfortunate, it really
> doesn't give me warm fuzzy feelings :( libvirt really should not know
> about internals of image formats.

But even if you add new features to qemu to avoid needing this in the 
future, it doesn't change the past - libvirt will always have to know 
how to parse image files understood by older qemu, and so as long as 
libvirt already knows how to do that parsing, we might as well take 
advantage of it.

Besides, I feel that having a well-documented file format, so that 
independent applications can both parse the same file with the same 
semantics by obeying the file format specification, is a good design goal.

> > It would be nice if libvirt had a way to pass fds for every disk and
> > backing file up front; then, SELinux can work around the lack of NFS
> > per-file labelling by blocking open() in qemu.  In fact, this has
> > already been proposed:
>
> A cleaner solution seems to have libvirt provide a call-back allowing
> QEMU to call out and have libvirt open a file descriptor instead. This
> way libvirt can validate it and open it for QEMU and pass it back.

Yes, that could probably be made to work with libvirt.

> If we cannot do something like this, I would prefer to have backing
> files on NFS should simply not be supported when running in an selinux
> setup.

As nice as that sentiment is, it will never fly, because it would be a 
regression in current behavior.  The whole reason that the virt_use_nfs 
SELinux bool exists is that some people are willing to make the partial 
security tradeoff.  Besides, the use of sVirt via SELinux is more than 
just open() protection - while the current virt_use_nfs bool makes NFS 
less secure than otherwise possible, it still gives some nice guarantees 
to the rest of the qemu process such as passthrough accesses to local 
pci devices.

Just because it is currently not as secure to mix NFS shared storage 
with backing files doesn't stop some people from wanting to do it [in 
fact, that's my current development setup - I use qcow2 images on NFS 
shared storage, keep SELinux enabled, and enable the virt_use_nfs bool]. 
 This discussion is about adding enhancements that make SELinux even 
more powerful when using NFS shared storage, by adding fd passing 
(whether libvirt parses in advance, or whether qemu raises an event and 
requires feedback from libvirt), and not about crippling the existing 
capability to use the virt_use_nfs selinux bool.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org