From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvtT7-0000U6-Ls for qemu-devel@nongnu.org; Tue, 23 Aug 2011 12:04:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvtT5-0001sm-LE for qemu-devel@nongnu.org; Tue, 23 Aug 2011 12:04:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvtT5-0001se-Cj for qemu-devel@nongnu.org; Tue, 23 Aug 2011 12:04:47 -0400 Date: Tue, 23 Aug 2011 17:04:34 +0100 From: "Daniel P. Berrange" Message-ID: <20110823160434.GN5728@redhat.com> References: <20110822162444.GI9456@redhat.com> <4E5283D8.9000309@codemonkey.ws> <20110822165014.GM9456@redhat.com> <4E529105.2010907@us.ibm.com> <4E5294EA.1050007@linux.vnet.ibm.com> <4E53C39E.9090206@linux.vnet.ibm.com> <20110823152655.GG5728@redhat.com> <4E53CC2B.4000604@redhat.com> <20110823155131.GM5728@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110823155131.GM5728@redhat.com> Subject: Re: [Qemu-devel] [libvirt] [PATCH v4] Add support for fd: protocol Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: libvir-list@redhat.com, Blue Swirl , Anthony Liguori , qemu-devel@nongnu.org, Christoph Hellwig 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 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 :|