On Fri, Nov 08, 2019 at 12:17:41PM +0100, Stefan Hajnoczi wrote: > On Thu, Nov 07, 2019 at 09:33:45AM -0500, Michael S. Tsirkin wrote: > > On Thu, Nov 07, 2019 at 03:02:20PM +0100, Stefan Hajnoczi wrote: > > > This documentation suggests that QEMU spawns the remote processes. How > > > do this work with unprivileged QEMU? Is there an additional step where > > > QEMU drops privileges after having spawned remote processes? > > > > > > Remote processes require accesses to resources that the main QEMU > > > process does not need access to, so I'm wondering how this process model > > > ensures that each process has only the privileges it needs. > > > > I guess you have something like capabilities in mind? > > Or namespaces (unshare(2)). > > > When using something like selinux, priviledges are per binary > > so the order of startup doesn't matter. > > For static SELinux policies that make sense, thanks for explaining. > > Does libvirt also perform dynamic (i.e. per-instance) SELinux > configuration? I guess that cannot be associated with a specific binary > because multiple QEMU instances launch the same binary yet need to be > differentiated.
In a traditional SELinux approach, the SELinux context used for any process is determined by a combination of the label on the binary and a transition rule. eg if the qemu-system-x86_64 file is labelled qemu_exec_t, and there's a context qemu_t for the QEMU process, a transition rule is defined "virtd_t + qemu_exec_t -> qemu_t". This says that when a process with context "vird_t" execs a binary labelled qemu_exec_t, the new process gets qemu_t. We sVirt, however, we can't rely on automatic transitions, because we need to assign a unique MCS tag for each VM. Thus libvird will explicitly tell SELinux what label to apply. In the case of multiprocess QEMU, if using sVirt from libvirt, then we'll need to continue setting the explicit labels as we'll still need the MCS tags for each helper process. If not using libvirt and sVirt, and wanting automatic SELinux transitions for QEMU helper processes, then each helper would need to be a separate binary on disk so that each helper can be given a distinct file label, which in turns lets you define a set of transitions for each helper according to its expected access needs. Having said all that I don't think its worth worrying about this. Anyone who cares about SELinux with QEMU will want to be using sVirt or an equivalent approach to assign unique MCS per VM. And thus automatic transitions are not possible even if we had distinct binaries for each helper. 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 :|
