Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/01/2012 04:45 PM, Corey Bryant wrote:
>
>
> On 05/01/2012 04:25 PM, Anthony Liguori wrote:
>> Thanks for sending this out Stefan.
>>
>> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
>>> Libvirt can take advantage of SELinux to restrict the QEMU process and
>>> prevent
>>> it from opening files that it should not have access to. This improves
>>> security because it prevents the attacker from escaping the QEMU
>>> process if
>>> they manage to gain control.
>>>
>>> NFS has been a pain point for SELinux because it does not support
>>> labels (which
>>> I believe are stored in extended attributes). In other words, it's not
>>> possible to use SELinux goodness on QEMU when image files are located
>>> on NFS.
>>> Today we have to allow QEMU access to any file on the NFS export
>>> rather than
>>> restricting specifically to the image files that the guest requires.
>>>
>>> File descriptor passing is a solution to this problem and might also
>>> come in
>>> handy elsewhere. Libvirt or another external process chooses files
>>> which QEMU
>>> is allowed to access and provides just those file descriptors - QEMU
>>> cannot
>>> open the files itself.
>>>
>>> This series adds the -open-hook-fd command-line option. Whenever QEMU
>>> needs to
>>> open an image file it sends a request over the given UNIX domain
>>> socket. The
>>> response includes the file descriptor or an errno on failure. Please
>>> see the
>>> patches for details on the protocol.
>>>
>>> The -open-hook-fd approach allows QEMU to support file descriptor passing
>>> without changing -drive. It also supports snapshot_blkdev and other
>>> commands
>>> that re-open image files.
>>>
>>> Anthony Liguori<aliguori@us.ibm.com> wrote most of these patches. I
>>> added a
>>> demo -open-hook-fd server and added some small fixes. Since Anthony is
>>> traveling right now I'm sending the RFC for discussion.
>>
>> What I like about this approach is that it's useful outside the block
>> layer and is conceptionally simple from a QEMU PoV. We simply delegate
>> open() to libvirt and let libvirt enforce whatever rules it wants.
>>
>> This is not meant to be an alternative to blockdev, but even with
>> blockdev, I think we still want to use a mechanism like this even with
>> blockdev.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>
> I like it too and I think it's a better solution than the fd: protocol approach.
>
> I think (correct me if I'm wrong) libvirt should be aware of any file that qemu
> asks it to open. So from a security point of view, libvirt can prevent opening a
> file if it isn't affiliated with the guest.

Right, libvirt can maintain a whitelist of files QEMU is allowed to open (which 
is already has because it needs to label these files).  The only complexity is 
that it's not a straight strcmp().  The path needs to be (carefully) broken into 
components with '.' and '..' handled appropriately.  But this shouldn't be that 
difficult to do.

Regards,

Anthony Liguori

>