[libvirt] New QEMU daemon for persistent reservations

[Paolo Bonzini]

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