From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvsgk-00078W-QR for qemu-devel@nongnu.org; Tue, 23 Aug 2011 11:14:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qvsgj-0006yb-Dc for qemu-devel@nongnu.org; Tue, 23 Aug 2011 11:14:50 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:46688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvsgj-0006yL-74 for qemu-devel@nongnu.org; Tue, 23 Aug 2011 11:14:49 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7NF13gY004625 for ; Tue, 23 Aug 2011 11:01:03 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7NFEicZ223244 for ; Tue, 23 Aug 2011 11:14:44 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7NFDZcF006931 for ; Tue, 23 Aug 2011 09:13:36 -0600 Message-ID: <4E53C39E.9090206@linux.vnet.ibm.com> Date: Tue, 23 Aug 2011 11:13:34 -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> In-Reply-To: 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: Blue Swirl Cc: kwolf@redhat.com, libvir-list@redhat.com, Anthony Liguori , Christoph Hellwig , qemu-devel@nongnu.org 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. -- Regards, Corey >> > Regards, >> > Corey >> > >>>> >>> 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_addfile:/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. >>> >> >>>> >>> So I'd see that you'd likely end up with the >>>> >>> qemu-fe security policy being identical to the qemu security policy, >>> >> >>> >> Then there's no point in doing qemu-fe. qemu-fe should be thought of as >>> >> QEMU supplied libvirtd plugin. >>> >> >>>> >>> with the exception that it would be allowed to open files on NFS without >>>> >>> needing them to be labelled. So I don't really see that all this gives us >>>> >>> any tangible benefits over just allowing the mgmt app to pass in the FDs >>>> >>> directly. >>>> >>> >>>>> >>>> But libvirt would still need to parse image files. >>>> >>> >>>> >>> Not neccessarily. As mentioned below, it is entirely possible to >>>> >>> enable the mgmt app to pass in details of the backing files, at >>>> >>> which point no image parsing is required by libvirt. Hence my >>>> >>> assertion that the question of who does image parsing is irrelevant >>>> >>> to this discussion. >>> >> >>> >> That's certainly true. >>> >> >>> >> Regards, >>> >> >>> >> Anthony Liguori >> > >> > >> >