On Fri, May 20, 2011 at 02:48:23PM -0400, Corey Bryant wrote: > sVirt provides SELinux MAC isolation for Qemu guest processes and their > corresponding resources (image files). sVirt provides this support > by labeling guests and resources with security labels that are stored > in file system extended attributes. Some file systems, such as NFS, do > not support the extended attribute security namespace, which is needed > for image file isolation when using the sVirt SELinux security driver > in libvirt. > > The proposed solution entails a combination of Qemu, libvirt, and > SELinux patches that work together to isolate multiple guests' images > when they're stored in the same NFS mount. This results in an > environment where sVirt isolation and NFS image file isolation can both > be provided. > > Currently, Qemu opens an image file in addition to performing the > necessary read and write operations. The proposed solution will move > the open out of Qemu and into libvirt. Once libvirt opens an image > file for the guest, it will pass the file descriptor to Qemu via a > new fd: protocol. > > If the image file resides in an NFS mount, the following SELinux policy > changes will provide image isolation: > > - A new SELinux boolean is created (e.g. virt_read_write_nfs) to > allow Qemu (svirt_t) to only have SELinux read and write > permissions on nfs_t files > > - Qemu (svirt_t) also gets SELinux use permissions on libvirt > (virtd_t) file descriptors > > Following is a sample invocation of Qemu using the fd: protocol: > > qemu -drive file=fd:4,format=qcow2 > > This patch contains the Qemu code to support this solution. I would > like to solicit input from the libvirt community prior to starting > the libvirt patch. > > This patch was tested with the following formats: raw, cow, qcow, > qcow2, vmdk, using the fd: protocol as well as existing file name > support. Non-valid file descriptors were also tested.
How can backing files work ? The '-drive' syntax doesn't provide any way to set properties against the backing files (which may be nested to arbitrary depth). AFAICT, we need to the often discussed -blockdev advanced syntax to be able to set a 'fd' property against nested backing files. I'm not sure it is worth supporting fd: if we only have -drive syntax, since backing files are an important feature for most mgmt apps. Also, there are a few places in QEMU, where it re-opens the existing block driver on the fly. What is the plan for supporting this, without having QEMU block on waiting for libvirt to pass it a new FD ? Regards, 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 :|
