Re: [Qemu-devel] live snapshot wiki updated

[Jes Sorensen <Jes.Sorensen@redhat.com>]

On 07/19/11 18:14, Anthony Liguori wrote:
>>> 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.
>>
>> Well leaving things at status quo is not making it worse, it just leaves
>> an evil in place.
> 
> NFS and SELinux is a fundamental problem with SELinux and NFS.  We can
> piss and moan as much as we want about it but it's reality.  SELinux
> fundamentally requires extended attributes.  By the time NFS adds
> extended attribute support, we'll all be flying around in hover cars.
> 
> As terrible as NFS is, people use it all of the time.
> 
> It would be nice if libvirt had the ability to make better use of DAC to
> support isolation.  The fact that MAC is the only way you can do
> isolation between guests is pretty unfortunate.  If I could assign
> specific UIDs to a guest and use that to enforce isolation, it would go
> a long ways to solving this problem.

Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around the problem. In a sane world we would simply
say 'no NFS, no selinux', but as you say that will never happen.

My suggestion of a callback mechanism where libvirt registers the
callback with QEMU for open() calls, allowing libvirt to perform the
open and return the open file descriptor would get around this problem.

Jes