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

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: elena.ufimtseva@oracle.com, john.g.johnson@oracle.com,
	sstabellini@kernel.org, jag.raman@oracle.com,
	konrad.wilk@oracle.com, qemu-devel@nongnu.org,
	ross.lagerwall@citrix.com, liran.alon@oracle.com,
	stefanha@redhat.com, kanth.ghatraju@oracle.com
Subject: Re: [Qemu-devel] [multiprocess RFC PATCH 36/37] multi-process: add the concept description to docs/devel/qemu-multiprocess
Date: Thu, 7 Mar 2019 14:51:20 +0000	[thread overview]
Message-ID: <20190307145120.GF32268@redhat.com> (raw)
In-Reply-To: <20190307142609.GF2843@stefanha-x1.localdomain>

On Thu, Mar 07, 2019 at 02:26:09PM +0000, Stefan Hajnoczi wrote:
> On Wed, Mar 06, 2019 at 11:22:53PM -0800, elena.ufimtseva@oracle.com wrote:
> > diff --git a/docs/devel/qemu-multiprocess.txt b/docs/devel/qemu-multiprocess.txt
> > new file mode 100644
> > index 0000000..e29c6c8
> > --- /dev/null
> > +++ b/docs/devel/qemu-multiprocess.txt
> 
> Thanks for this document and the interesting work that you are doing.
> I'd like to discuss the security advantages gained by disaggregating
> QEMU in more detail.
> 
> The security model for VMs managed by libvirt (most production x86, ppc,
> s390 guests) is that the QEMU process is untrusted and only has access
> to resources belonging to the guest.  SELinux is used to restrict the
> process from accessing other files, processes, etc on the host.

NB it doesn't have to be SELinux. Libvirt also supports AppArmor and
can even do isolation with traditional DAC by putting each QEMU under
a distinct UID/GID and having libvirtd set ownership on resources each
VM is permitted to use.

> QEMU does not hold privileged resources that must be kept away from the
> guest.  An escaped guest can access its image file, tap file descriptor,
> etc but they are the same resources it could already access via device
> emulation.
> 
> Can you give specific examples of how disaggregation improves security?

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.

Not everything is protected by MAC/DAC. For example network based disks
typically have a username + password for accessing the remote storage
server. Best practice would be a distinct username for every QEMU process
such that each can only access its own storage, but I don't know of any
app which does that. So ability to split off backends into separate
processes could limit exposure of information that is not otherwise
protected by current protection models.

Whether any of this is useful in practice depends on the degree to
which the individual disaggregated pieces of QEMU trust each other.
Effectively they would have to consider each other as untrusted,
so one compromised piece can't simply trigger its desired exploit
via the communication channel with another disaggregated piece.

The broadening of vhost-user support is useful with that in much the
same way I imagine.

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