On Mon, Sep 11, 2017 at 04:23:27PM +0200, Paolo Bonzini wrote: > On 11/09/2017 14:09, Daniel P. Berrange wrote: > > On Mon, Sep 11, 2017 at 01:44:59PM +0200, Paolo Bonzini wrote: > >> On 11/09/2017 12:46, Daniel P. Berrange wrote: > >>>> So the helper is a bit different from QEMU with respect to both SELinux > >>>> MCS labeling and the devices cgroup. Access limitation comes from only > >>>> ever operating on devices that have been passed on the socket. SELinux > >>>> MCS could be used so that only the "right" QEMU can connect to each > >>>> instance of the helper, though. > >>> I wonder how this interacts with SELinux. IIUC if we grant access to > >>> the multipath device file, the kernel won't normally require us to > >>> grant access the underlying paths. I/O is just allowed because they > >>> are a member of the mpath device. Hopefully this applies to the > >>> persistent reservations too ? > >> > >> No, persistent reservations are special; they have to be registered > >> independently on each path. (As I said, this was the original reason to > >> have a separate daemon: implementing it in QEMU would be not just a bad > >> idea because you need CAP_SYS_ADMIN, it would be impossible for > >> libvirt-started guests because of sVirt and device cgroups). > >> > >> So I think the helper daemon needs to be granted blanket ioctl access to > >> devices, without using either device cgroups or MCS. > > > > If it was a single helper daemon for all guests, that would be ok to be > > granted access to all devices. If we did that though, the daemon would > > have to be SELinux aware. ie, libvirt would have to talk to it and say > > that svirt_t:s0:c236,c660 is permitted /dev/mpath/foo, and it would > > have to validate the requests from the socket to QEMU to make sure that > > QEMU is not requesting access to other mpath devices. > > This is already handled via SCM_RIGHTS and is part of the design of the > helper daemon. QEMU cannot even open mpath devices which are not > accessible according to its SELinux category or device cgroup. Ah so the daemon relies on the fact that the client was not permitted to open another file. So the only FD it can receive from the client is one that was associated with a permitted mpath device. That would be sufficient to protect against a malicious qemu process trying to explicitly pass it invalid FD data. It wouldn't be sufficient to be safe against a QEMU process that somehow managed to trigger a bug that caused it to corrupt memory and thus trick into opening a different file. For the latter we would need to have some stricter policy about the helper daemon and labelling on files. 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
