[libvirt] New QEMU daemon for persistent reservations

Daniel P. Berrange berrange at redhat.com
Mon Sep 11 12:09:57 UTC 2017


On Mon, Sep 11, 2017 at 01:44:59PM +0200, Paolo Bonzini wrote:
> On 11/09/2017 12:46, Daniel P. Berrange wrote:
> >> So the helper is a bit different from QEMU with respect to both SELinux
> >> MCS labeling and the devices cgroup.  Access limitation comes from only
> >> ever operating on devices that have been passed on the socket.  SELinux
> >> MCS could be used so that only the "right" QEMU can connect to each
> >> instance of the helper, though.
> > I wonder how this interacts with SELinux. IIUC if we grant access to
> > the multipath device file, the kernel won't normally require us to
> > grant access the underlying paths. I/O is just allowed because they
> > are a member of the mpath device. Hopefully this applies to the
> > persistent reservations too ?
> 
> No, persistent reservations are special; they have to be registered
> independently on each path.  (As I said, this was the original reason to
> have a separate daemon: implementing it in QEMU would be not just a bad
> idea because you need CAP_SYS_ADMIN, it would be impossible for
> libvirt-started guests because of sVirt and device cgroups).
> 
> So I think the helper daemon needs to be granted blanket ioctl access to
> devices, without using either device cgroups or MCS.

If it was a single helper daemon for all guests, that would be ok to be
granted access to all devices. If we did that though, the daemon would
have to be SELinux aware. ie, libvirt would have to talk to it and say
that svirt_t:s0:c236,c660 is permitted /dev/mpath/foo, and it would
have to validate the requests from the socket to QEMU to make sure that
QEMU is not requesting access to other mpath devices.

If it was a one helper daemon per QEMU instance, then we would want to
directly confine it to just the underlying devices associated with the
mpath device allowed for that QEMU instance. This would imply that we
needed to label the underlying devices with the MCS label to match the
VM.

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




More information about the libvir-list mailing list