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

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.