Re: [Qemu-devel] [multiprocess RFC PATCH 36/37] multi-process: add the concept description to docs/devel/qemu-multiprocess

[Daniel P . Berrangé]

On Thu, Mar 21, 2019 at 08:26:47PM -0700, John G Johnson wrote:
> 
>  
> >  On Thu, Mar 07, 2019 at 02:51:20PM +0000, Daniel P. Berrangé wrote:
> > 
> >> On Mar 7, 2019, at 11:27 AM, Stefan Hajnoczi <address@hidden> wrote:
> >>> 
> >>> On Thu, Mar 07, 2019 at 02:51:20PM +0000, Daniel P. Berrangé wrote:
> >>>> I guess one obvious answer is that the existing security mechanisms like
> >>>> SELinux/ApArmor/DAC can be made to work in a more fine grained manner if
> >>>> there are distinct processes. This would allow for a more useful seccomp
> >>>> filter to better protect against secondary kernel exploits should QEMU
> >>>> itself be exploited, if we can protect individual components.
> >>> 
> >>> Fine-grained sandboxing is possible in theory but tedious in practice.
> >>> From what I can tell this patch series doesn't implement any sandboxing
> >>> for child processes.
> >>> 
> >> 
> >>     The policies aren’t in QEMU, but in the selinux config files.
> >> They would say, for example, that when the QEMU process exec()s the
> >> disk emulation process, the process security context type transitions
> >> to a new type.  This type would have permission to access the VM image
> >> objects, whereas the QEMU process type (and any other device emulation
> >> process types) cannot access them.
> > 
> > 
> > Note that currently all QEMU instances run by libvirt have seccomp
> > policy applied that explicitly forbids any use of fork+exec as a way
> > to reduce avenues of attack for an exploited QEMU.
> > 
> > Even in a modularized QEMU I'd be loathe to allow QEMU to have the
> > fork+exec privileged, unless "QEMU" in this case was just a stub
> > process that does nothing more than fork+exec the other binaries,
> > while having zero attack exposed to the untrusted guest OS.
> > 
> 
>       We’re looking at a couple ways to address your concerns.
> One is a stub process, as you mentioned above, but if we need to
> create programming to fork() and exec() the required emulation
> programs before exec()ing QEMU, then it may make sense to just put
> that programming into libvirt itself.
> 
>       Both paths would need similar changes to QEMU, such as the
> ability to receive descriptions of the emulation processes the parent
> process has created, and file descriptors that it has setup to
> communicate with them.  Each remote device would then be matched with
> its corresponding external process.
> 
>       The difference would be whether to create a new stub program
> to create the emulation processes, or delegate that task to libvirt’s
> QEMU driver.
> 
>       Do you have an opinion on a stub program vs libvirt integration?

Libvirt preference would be to retain full control over what programs
are spawned. This allows us to control their resource usage / placement
/ security policies. Having a stub that hides this from libvirt will
make this control harder, as we'll then need to interogate the stub
to find out what it did & applying controls appropriately. Also if more
external processes need to be spawned when hotplugging a device, then
libvirt would definitely want to have full control, as once QEMU vCPUS
have been started we don't trust it.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|