From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvryK-0005b8-4z for qemu-devel@nongnu.org; Tue, 23 Aug 2011 10:28:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvryI-0005OY-Pg for qemu-devel@nongnu.org; Tue, 23 Aug 2011 10:28:56 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:32961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvryI-0005OM-N6 for qemu-devel@nongnu.org; Tue, 23 Aug 2011 10:28:54 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7NDt1r3031266 for ; Tue, 23 Aug 2011 09:55:01 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7NER3iw220536 for ; Tue, 23 Aug 2011 10:28:49 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7NEQMT4026500 for ; Tue, 23 Aug 2011 11:26:22 -0300 Message-ID: <4E53B88C.1020300@linux.vnet.ibm.com> Date: Tue, 23 Aug 2011 10:26:20 -0400 From: Corey Bryant MIME-Version: 1.0 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> <20110822182210.GA31225@redhat.com> <4E52AD18.9010907@us.ibm.com> In-Reply-To: <4E52AD18.9010907@us.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCH v4] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kwolf@redhat.com, libvir-list@redhat.com, Christoph Hellwig , qemu-devel@nongnu.org On 08/22/2011 03:25 PM, Anthony Liguori wrote: > On 08/22/2011 01:22 PM, Daniel P. Berrange wrote: >> 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. > > But the fundamental difference is that libvirtd uses what's ostensible a > public, supported interface. That means when we add things like this, > we're stuck supporting it for general use cases. > > It's much more palatable to do these things using a private interface > such that we can change these things down the road without worrying > about compatibility with third-party tools. > > Regards, > > Anthony Liguori > Is this a nack for the fd: protocol? Or do we want to implement the fd: protocol as a stepping stone on the way to a privilege-separated qemu model? I know the fd: protocol is not ideal, but it does provide NFS image isolation, perhaps much sooner than privilege-separated qemu can. -- Regards, Corey