[libvirt] New QEMU daemon for persistent reservations

[Daniel P. Berrange]

On Mon, Nov 27, 2017 at 12:13:24PM +0100, Paolo Bonzini wrote:
> On 27/11/2017 11:59, Daniel P. Berrange wrote:
> > On Mon, Nov 27, 2017 at 11:57:56AM +0100, Paolo Bonzini wrote:
> >> On 27/11/2017 10:40, Daniel P. Berrange wrote:
> >>>
> >>> If we had one daemon per QEMU, then we would give the daemon the same
> >>> MCS label as QEMU. The kernel will thus enforce this label matches the
> >>> label on the QEMU process when it connects to the UNIX socket. The kernel
> >>> will also validate the label on the disk file descriptor passed to the
> >>> daemon by QEMU.
> >>>
> >>> If we had one daemon per host, then that daemon will need a generic
> >>> label that lets all QEMUs connect to it. When QEMU passes in a disk
> >>> FD, the daemon will need to query the SELinux context of the remote
> >>> QEMU process, and then perform a userspace ACL check of that against
> >>> the FD that is passed in.
> >>>
> >>> The latter case means the QEMU helper will need to link to libselinux
> >>> and performs checks itself.
> >>
> >> Then it seems much better to use one daemon per QEMU, indeed.
> > 
> > That would rule out using persistent reservations for unprivileged QEMU
> > though, because we still need sVirt protection for that.
> 
> 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.

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.

Userspace MAC checks are not very hard to do, so I don't see a significant
burden to adding this support to the helper.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|