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

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

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.

-- 
Regards,
Corey

>>
>> Anthony Liguori (3):
>> block: add open() wrapper that can be hooked by libvirt
>> block: add new command line parameter that and protocol description
>> block: plumb up open-hook-fd option
>>
>> Stefan Hajnoczi (2):
>> osdep: add qemu_recvmsg() wrapper
>> Example -open-hook-fd server
>>
>> block.c | 107 ++++++++++++++++++++++++++++++++++++++
>> block.h | 2 +
>> block/raw-posix.c | 18 +++----
>> block/raw-win32.c | 2 +-
>> block/vdi.c | 2 +-
>> block/vmdk.c | 6 +--
>> block/vpc.c | 2 +-
>> block/vvfat.c | 4 +-
>> block_int.h | 12 +++++
>> osdep.c | 46 +++++++++++++++++
>> qemu-common.h | 2 +
>> qemu-options.hx | 42 +++++++++++++++
>> test-fd-passing.c | 147
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> vl.c | 3 ++
>> 14 files changed, 378 insertions(+), 17 deletions(-)
>> create mode 100644 test-fd-passing.c
>>
>
>