Re: [libvirt] [Qemu-devel] [PATCH v4] Add support for fd: protocol

On Tue, Aug 23, 2011 at 05:50:03PM +0200, 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<coreyb(a)linux.vnet.ibm.com> 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. That's why I said a qemu-fe like tool need not be mutually exclusive with exposing FD passing to a management tool like libvirt. Both qemu-fe and libvirt need to some mechanism to pass open FDs to the real QEMU. We could needlessly invent a new communication channel between qemu-fe and qemu that only it can use, or we can use the channel we already have - QMP - to provide an interface that either qemu-fe or libvirt, can use to pass FDs into the real QEMU.