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

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(a)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.