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