Re: [libvirt] New QEMU daemon for persistent reservations
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.