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

[Corey Bryant]

On 08/22/2011 02:39 PM, Blue Swirl wrote:
> On Mon, Aug 22, 2011 at 5:42 PM, Corey Bryant<address@hidden>  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
> > >
> > >
> > >