From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvtcy-0007oI-4K for qemu-devel@nongnu.org; Tue, 23 Aug 2011 12:15:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qvtcw-0004XE-G5 for qemu-devel@nongnu.org; Tue, 23 Aug 2011 12:15:00 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]:56039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvtcw-0004Wj-DT for qemu-devel@nongnu.org; Tue, 23 Aug 2011 12:14:58 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7NFoRus012115 for ; Tue, 23 Aug 2011 11:50:27 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7NGEmLM137634 for ; Tue, 23 Aug 2011 12:14:49 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7NGEh14031576 for ; Tue, 23 Aug 2011 12:14:44 -0400 Message-ID: <4E53D1F1.409@linux.vnet.ibm.com> Date: Tue, 23 Aug 2011 12:14:41 -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> <4E5294EA.1050007@linux.vnet.ibm.com> <4E53C39E.9090206@linux.vnet.ibm.com> <20110823152655.GG5728@redhat.com> <4E53CC2B.4000604@redhat.com> In-Reply-To: <4E53CC2B.4000604@redhat.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: Kevin Wolf Cc: Anthony Liguori , libvir-list@redhat.com, qemu-devel@nongnu.org, Blue Swirl , Christoph Hellwig On 08/23/2011 11:50 AM, 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. > > Kevin True, but like you said it provides just some protection. To really be useful qemu-fe would need the ability to label qemu guest processes and image files to provide MAC isolation. -- Regards, Corey