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

[Stefan Hajnoczi]

On Thu, Mar 07, 2019 at 02:51:20PM +0000, Daniel P. Berrangé wrote:
> On Thu, Mar 07, 2019 at 02:26:09PM +0000, Stefan Hajnoczi wrote:
> > On Wed, Mar 06, 2019 at 11:22:53PM -0800, address@hidden 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?

Elena & collaborators: Dan has posted some ideas but please share yours
so the security benefits of this patch series can be better understood.

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

There must be a convenient way to get fine-grained sandboxing for
disaggregated devices.  In other words, it shouldn't be left as an
exercise to device process authors.

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?

 * We need to make sure that processes cannot send signals to each
   other, ptrace, interfere in /proc/$PID, etc.  How will this be done?

 * Were you planning to use any other sandboxing mechanisms
   (namespaces?)?  How will they be set up if the device processed is
   forked/executed by an unprivileged QEMU?

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

If the disaggregated disk process with a global username + password is
compromised then all your disk images are compromised.  So you still
need to follow the best practice of per-VM credentials even with
disaggregation, and if you do then disaggregation doesn't add anything!

Stefan

signature.asc
Description: PGP signature