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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
