From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvs2u-0007KC-Mw for qemu-devel@nongnu.org; Tue, 23 Aug 2011 10:33:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qvs2o-0006RP-P8 for qemu-devel@nongnu.org; Tue, 23 Aug 2011 10:33:40 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:48842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvs2o-0006RH-LJ for qemu-devel@nongnu.org; Tue, 23 Aug 2011 10:33:34 -0400 Received: by ywf9 with SMTP id 9so148564ywf.4 for ; Tue, 23 Aug 2011 07:33:34 -0700 (PDT) Message-ID: <4E53BA3B.8050905@codemonkey.ws> Date: Tue, 23 Aug 2011 09:33:31 -0500 From: Anthony Liguori 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> <4E53B88C.1020300@linux.vnet.ibm.com> In-Reply-To: <4E53B88C.1020300@linux.vnet.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: Corey Bryant Cc: kwolf@redhat.com, libvir-list@redhat.com, Anthony Liguori , Christoph Hellwig , qemu-devel@nongnu.org On 08/23/2011 09:26 AM, Corey Bryant wrote: > 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? No, I think we're trying to understand what the options are. Regards, Anthony Liguori 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. >