Re: [Qemu-devel] [libvirt] [PATCH v4] Add support for fd: protocol

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Aug 23, 2011 at 11:13:34AM -0400, Corey Bryant wrote:
> 
> 
> On 08/22/2011 02:39 PM, Blue Swirl wrote:
> >On Mon, Aug 22, 2011 at 5:42 PM, Corey Bryant<coreyb@linux.vnet.ibm.com>  wrote:
> >>>
> >>>
> >>>  On 08/22/2011 01:25 PM, Anthony Liguori wrote:
> >>>>>
> >>>>>  On 08/22/2011 11:50 AM, Daniel P. Berrange wrote:
> >>>>>>>
> >>>>>>>  On Mon, Aug 22, 2011 at 11:29:12AM -0500, Anthony Liguori wrote:
> >>>>>>>>>
> >>>>>>>>>  I don't think it makes sense to have qemu-fe do dynamic labelling.
> >>>>>>>>>  You certainly could avoid the fd passing by having qemu-fe do the
> >>>>>>>>>  open though and just let qemu-fe run without the restricted security
> >>>>>>>>>  context.
> >>>>>>>
> >>>>>>>  qemu-fe would also not be entirely simple,
> >>>>>
> >>>>>  Indeed.
> >>>>>
> >>>
> >>>  I do like the idea of a privileged qemu-fe performing the open and passing
> >>>  the fd to a restricted qemu.
> >Me too.
> >
> >>>    However, I get the impression that this won't
> >>>  get delivered nearly as quickly as fd: passing could be.  How soon do we
> >>>  need image isolation for NFS?
> >>>
> >>>  Btw, this sounds similar to what Blue Swirl recommended here on v1 of this
> >>>  patch:http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02187.html
> >I was thinking about simply doing fork() + setuid() at some point and
> >using the FD passing structures directly. But would it bring
> >advantages to have two separate executables, are they different from
> >access control point of view vs. single but forked one?
> >
> 
> We could put together an SELinux policy that would transition
> qemu-fe to a more restricted domain (ie. no open privilege on NFS
> files) when it executes qemu-system-x86_64.

Thinking about this some more, I don't really think the idea of delegating
open of NFS files to a separate qemu-fe is very desirable. Libvirt makes the
decision on the security policy that the VM will run under, and provides
audit records to log what resources are being assigned to the VM. From that
point onwards, we must be able to guarantee that MAC will be enforced on
the VM, according to what we logged via the auditd system.

In the case where we delegate opening of the files to qemu-fe, and allow
its policy to open NFS files, we no longer have a guarentee that the MAC
policy will be enforced as we originally intended. Yes, qemu-fe will very
likely honour what we tell it and open the correct files, and yes qmeu-fe
has lower attack surface wrt the guest than the real qemu does, but we
still loose the guarentee of MAC enforcement from libvirt's POV.

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