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