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