[libvirt] New QEMU daemon for persistent reservations

[Paolo Bonzini]

On 27/11/2017 12:37, Daniel P. Berrange wrote:
> On Mon, Nov 27, 2017 at 12:13:24PM +0100, Paolo Bonzini wrote:
>> Hm, I see what you mean now.  But it would be "just" a qemu-pr-helper
>> bug that it trusts the caller to have "ioctl" permissions on the file
>> descriptor, wouldn't it?
>>
>> And it could be a feature even, since the remote QEMU process also has
>> to have "connect" permissions on the qemu-pr-helper socket.  So you
>> could give it ioctl access *limited to persistent reservations* by
>> granting the appropriate permissions on the socket.
> 
> We can't grant access to the persistent reservation helper's socket on a
> per QEMU basis. Permissions are granted on the domain type svirt_t, and
> we don't want to invent a new domain type just for having access to the
> PR helper.

You can do so via DAC and MAC on the socket itself, or is that not enough?

In other words, what are the SELinux best practices when you don't want
a process to have blanket access to a permission, but you may be fine
with a subset of those?  If you think of unpriv_sgio=0 as a very simple
MAC, this is actually the very case that the PR helper is designed for.

Thanks,

Paolo

> So if we grant access to a global PR helper, we must have that helper
> do MAC checks. Without it, QEMU has delegated actions it can't do itself
> to a separate process thus escaping its MAC confinement in that area.