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

[Elena Ufimtseva <elena.ufimtseva@oracle.com>]

On Mon, Mar 11, 2019 at 10:20:06AM +0000, Daniel P. Berrangé wrote:
> On Thu, Mar 07, 2019 at 03:29:41PM -0800, John G Johnson wrote:
> > 
> > 

Hi Daniel, Stefan

We have not replied in a while as we were trying to figure out
the best approach after multiple comments we have received on the
patch series.

Leaving other concerns that you, Stefan and others shared with us
out of this particular topic, we would like to get your opinion on
the following approach.

Please see below.

> > > On Mar 7, 2019, at 11:27 AM, Stefan Hajnoczi <stefanha@redhat.com> 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 see libvirt uses QEMU’s -sandbox option to indicate that QEMU
should use seccomp() to prohibit future use of certain system calls,
including fork() and exec().  Our idea is to enumerate the remote
processes needed via QEMU command line options, and have QEMU exec()
those processes before -sandbox is processed.
And we also will init seccomp for emulated devices processes.

> 
> > 	If you wanted to use DAC, you could do the something similar by
> > making the disk emulation executable setuid to a UID than can access
> > VM image files.
> > 
> > 	In either case, the policies and permissions are set up before
> > libvirt even runs, so it doesn’t need to be aware of them.
> 
> That's not the case bearing in mind the above point about fork+exec
> being forbidden. It would likely require libvirt to be in charge of
> spawning the various helper binaries from a trusted context.
> 
> 
> > > How to do this in practice must be clear from the beginning if
> > > fine-grained sandboxing is the main selling point.
> > > 
> > > Some details to start the discussion:
> > > 
> > > * How will fine-grained SELinux/AppArmor/DAC policies be configured for
> > >   each process?  I guess this requires root, so does libvirt need to
> > >   know about each process?
> > > 
> > 
> > 	The polices would apply to process security context types (or
> > UIDs in a DAC regime), so I would not expect libvirt to be aware of them.
> 
> I'm pretty skeptical that such a large modularization of QEMU can be
> done without libvirt being aware of it & needing some kind of changes
> applied.
>

We agree with that. With above proposed approach we still have to change hotplug
in some way.
If a eparate process will be spawned, libvirt will be the one doing
fork/exec of the separate processes. Or possibly launch a helper
binaries that will unify the way how an instance is being started with
multiple processes and hotplugging.

Thanks!
Elena, Jag, John.


> 
> 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 :|