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