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

[John G Johnson]

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

                                                JJ