[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd
Date: Wed, 2 May 2012 10:01:42 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, May 01, 2012 at 04:31:42PM +0100, 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.

While it would work, I really am not a fan of this approach overall, since
I think it adds significant complexity & great potential for problems. In
particular the potential for deadlock between the mgmt app & QEMU (sure
we should design to avoid deadlocks, but mistakes happen). It is also not
resilient against the mgmt app going away (whether due to crash, or intentional
restart for RPM upgrades). I strongly prefer to see FDs being passed in at
time of device configuration/creation as with netdevs, and then fixing the
places which re-open files to not require that.

|: 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 :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]