[libvirt] New QEMU daemon for persistent reservations

[Daniel P. Berrange]

On Fri, Nov 24, 2017 at 04:42:00PM +0100, Paolo Bonzini wrote:
> On 24/11/2017 15:52, Daniel P. Berrange wrote:
> >> So what has been suggested so far is:
> >> 
> >>   <disk type='block' device='disk'>
> >>     <source dev='/dev/sda'>
> >>     <target dev='sda' bus='scsi'/>
> >>     <reservations enable='yes'/>
> >>   </disk>
> 
> <reservations> without an inner <source> element leaves libvirtd with
> the choice of a daemon per QEMU, or a daemon per host in a well-known
> location.  Unprivileged libvirtd would always use the latter; for
> privileged libvirtd it is implementation-defined.  I like it.
> 
> <reservations> with an inner <source> always gives a daemon per host in
> a custom location.  It can be used by either unprivileged or privileged
> libvirtd.
> 
> >> Now, my question is, in the first case - how should libvirt chose the
> >> path? Should it be different for each disk/domain? How is the daemon
> >> started in the first place - should libvirt start it? And when should
> >> libvirt kill it?
> >
> > The core question is one daemon per QEMU, or one daemon per host. I'd be
> > more inclined to have one daemon per QEMU so we always have isolation
> > and thus do't have to worry about a shared daemon being a potential
> > attack point between distinct QEMU's.
> 
> One daemon per QEMU is nicer IMO because it lets us do MCS.  Of course
> one daemon per QEMU can only apply to system libvirtd; session must use
> one daemon per host.
> 
> One daemon per host is easy, because it's just a couple new command-line
> options as far as libvirtd is concerned, but we need to check that it
> works well with MCS.

In both cases we can do MCS, but it would work differently.

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.

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 :|