[libvirt] New QEMU daemon for persistent reservations

[Paolo Bonzini]

On 11/09/2017 17:53, Daniel P. Berrange wrote:
> On Mon, Sep 11, 2017 at 05:47:28PM +0200, Paolo Bonzini wrote:
>> On 11/09/2017 17:33, Daniel P. Berrange wrote:
>>> On Mon, Sep 11, 2017 at 05:27:20PM +0200, Paolo Bonzini wrote:
>>>> On 11/09/2017 17:23, Daniel P. Berrange wrote:
>>>>>> On the other hand, the daemon has CAP_SYS_RAWIO and CAP_SYS_ADMIN, so if
>>>>>> you get memory corruption all bets are probably off anyway.
>>>>> That's where the benefit of strict selinux labelling comes in. If we had
>>>>> strict labelling of the individual paths below the device, then even if
>>>>> the daemon got corrupted, the policy would prevent it from doing any
>>>>> damage to the system beyond calling ioctl() the individual paths it had
>>>>> been granted. It wouldn't be able to access devices associated with
>>>>> the host OS mounts, or other non-VM related or non-multipath related
>>>>> block devices.
>>>>
>>>> Sure, but those capabilities let you do a lot of nasty things
>>>> indirectly, even within the constraints of the SELinux policy.
>>>>
>>>> For example, if you are able to reconfigure device mapper, you can
>>>> convince the kernel to write to any block device---even if you cannot
>>>> open it.  IDWEFAL (I don't write exploits for a living) but I'm sure
>>>> that's just scraping the surface.
>>>
>>> Surely we would not write an SELinux policy that allows this daemon
>>> to reconfigure device mapper.
>>>
>>> IIUC, all this daemon should need is the ability to request persistent
>>> reservations on the individual paths associated with the mpath device.
>>>
>>> Is it not possible to write a SElinux policy which allows that, without
>>> also allowing reconfiguration of device mapper.
>>
>> As far as I know, querying and reconfiguring the device mapper are both
>> done with ioctls on /dev/mapper/control, and both require CAP_SYS_ADMIN.
>>
>> Maybe future versions of Linux could change it to require CAP_SYS_ADMIN
>> only for reconfiguration, so that the PR helper daemon does not require
>> the capability anymore.  However, that would be independent from
>> SELinux, which only controls "ioctl" access without finer-grain choice
>> of which ioctls to allow.
> 
> I don't suppose that the LUNS behind a mpath device end up being
> surface in /sys/block anywhere do they ?

The LUNs actually can be identified via /sys/block/dm-NN/slaves (I
think), but you cannot find out if it's a mpath device in the first
place without a /dev/mapper/control ioctl.

>> I understand that you want to protect in depth, but unfortunately this
>> only works if all layers are aware of SELinux.  Luckily the daemon is
>> much, much smaller than QEMU, and so is the attack surface.
> 
> It would be ok if we think its possible to lock it down later (once any
> needed kernel enhancements are developed), without having to change the
> interaction between QEMU / libvirt / helper daemon.  I'm beginning to
> feel that is ok.

Yes, that's my reasoning as well.  We could (and perhaps should) still
look at MCS to block unwanted connections to the socket, though.

Paolo