From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvZ8i-00062f-Cg for qemu-devel@nongnu.org; Mon, 22 Aug 2011 14:22:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvZ8g-0001bY-Ud for qemu-devel@nongnu.org; Mon, 22 Aug 2011 14:22:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvZ8g-0001bR-Mh for qemu-devel@nongnu.org; Mon, 22 Aug 2011 14:22:22 -0400 Date: Mon, 22 Aug 2011 19:22:10 +0100 From: "Daniel P. Berrange" Message-ID: <20110822182210.GA31225@redhat.com> References: <1314024650-28510-1-git-send-email-coreyb@linux.vnet.ibm.com> <20110822153820.GA4774@lst.de> <20110822162444.GI9456@redhat.com> <4E5283D8.9000309@codemonkey.ws> <20110822165014.GM9456@redhat.com> <4E529105.2010907@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E529105.2010907@us.ibm.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: Anthony Liguori Cc: kwolf@redhat.com, libvir-list@redhat.com, Corey Bryant , Christoph Hellwig , qemu-devel@nongnu.org On Mon, Aug 22, 2011 at 12:25:25PM -0500, 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. > > >because it will need to act > >as a proxy for the monitor, in order to make hotplug work. ie the mgmt > >app would be sending 'drive_add file:/foo/bar' to qemu-fe, which would > >then have to open the file and send 'drive_add fd:NN' onto the real QEMU, > >and then pass the results on back. > > > >In addition qemu-fe would still have to be under some kind of restricted > >security context for it to be acceptable. This is going to want to be as > >locked down as possible. > > I think there's got to be some give and take here. > > It should at least be as locked down as libvirtd. From a security > point of view, we should be able to agree that we want libvirtd to > be as locked down as possible. > > But there shouldn't be a hard requirement to lock down qemu-fe more > than libvirtd. Instead, the requirement should be for qemu-fe to be > as/more vigilant in not trusting qemu-system-x86_64 as libvirtd is. > > The fundamental problem here, is that there is some logic in > libvirtd that rightly belongs in QEMU. In order to preserve the > security model, that means that we're going to have to take a > subsection of QEMU and trust it more. Well we have a process that makes security decisions, and a process which applies those security decisions and a process which is confined by those decisions. Currently libvirtd makes & applies the decisions, and qemu is confined. A qemu-fe model would mean that libvirt is making the decisions, but is then relying on qemu-fe to apply them. IMHO that split is undesirable, but that's besides the point, since this is not a decision that needs to be made now. 'qemu-fe' needs to have a way to communicate with the confined process ('qemu-system-XXX') to supply it the resources (file FDs) it needs to access. The requirements of such a comms channel for qemu-fe are going to be the same as those needed by libvirtd talking to QEMU today, or indeed by any process that is applying security decisions to QEMU. So inventing a 'qemu-fe' does not make the need for passing FDs into QEMU go away, nor does it improve/change the overall security of the architecture, it is merely a different architectural choice. It does however require alot more development work to create this new 'qemu-fe' program and get it debugged & generally usable in production deployments So adding FD passing to QEMU blocks creation of a 'qemu-fe' program, but is not dependant on it. Thus we can add FD passing to QEMU today and be a step closer to being able to create a 'qemu-fe' in the future, while also enabling libvirtd & other mgmt apps to take advantage of this to solve the immediate security problem we have with NFS today, without having to wait a months or years for 'qemu-fe' to get into a usable state. 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 :|