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

[Daniel P. Berrange]

On Tue, Aug 23, 2011 at 04:51:31PM +0100, Daniel P. Berrange wrote:
> On Tue, Aug 23, 2011 at 05:50:03PM +0200, Kevin Wolf wrote:
> > Am 23.08.2011 17:26, schrieb Daniel P. Berrange:
> > > 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<address@hidden>  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.
> > 
> > On the other hand, from a qemu POV libvirt is only one possible
> > management tool. In practice, another very popular "management tool" for
> > qemu is bash. With qemu-fe all the other tools, including direct
> > invocation from the command line, would get some protection, too.
> 
> That's why I said a qemu-fe like tool need not be mutually exclusive
> with exposing FD passing to a management tool like libvirt. Both
> qemu-fe and libvirt need to some mechanism to pass open FDs to the
> real QEMU.  We could needlessly invent a new communication channel
> between qemu-fe and qemu that only it can use, or we can use the
> channel we already have - QMP - to provide an interface that either
> qemu-fe or libvirt, can use to pass FDs into the real QEMU.

Or to put it another way...

It should be possible to build a 'qemu-fe' tool which does sandboxing
using soley the QEMU command line + QMP monitor. If this is not possible
then, IMHO, QMP should be considered incomplete / a failure, or may point
to other holes in QEMU's mgmt app APIs. eg perhaps it would demonstrate
that we do in fact need a libblockdriver.so for mgmt apps to query info
about disks.

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