On 11/09/2017 14:09, Daniel P. Berrange wrote: > 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. This is already handled via SCM_RIGHTS and is part of the design of the helper daemon. QEMU cannot even open mpath devices which are not accessible according to its SELinux category or device cgroup. > 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. This would be nice but not necessary, right? Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
