On Mon, May 23, 2011 at 1:50 PM, Anthony Liguori <aligu...@us.ibm.com> wrote:
> On 05/23/2011 04:45 AM, Daniel P. Berrange wrote:
>>
>> 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).
>
> This is orthogonal to having an fd: protocol.
>
>> 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 ?
>
> That's only host CDROM AFAICT.
The host page cache on|off option also uses it because fcntl(2) cannot
change O_DIRECT. Actually for Linux it may be doable with
open('/proc/fd/<old>', flags ^ O_DIRECT) and on other hosts SELinux
does not exist.
On the other hand fcntl(2) should really support changing O_DIRECT -
only that there is not much incentive to fix Linux if other OSes don't
support it either (and older Linux kernels also require workarounds).
Stefan
