On Mon, Sep 11, 2017 at 05:20:10PM +0200, Paolo Bonzini wrote: > On 11/09/2017 16:32, Daniel P. Berrange wrote: > >> 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. > > Exactly. The passed file descriptor acts as a "capability"; the daemon > goes from there to the paths through fstat on the file descriptor > followed by /dev/mapper/control APIs (mostly issued by libmpathpersist). > > On the other hand, the daemon has CAP_SYS_RAWIO and CAP_SYS_ADMIN, so if > you get memory corruption all bets are probably off anyway. That's where the benefit of strict selinux labelling comes in. If we had strict labelling of the individual paths below the device, then even if the daemon got corrupted, the policy would prevent it from doing any damage to the system beyond calling ioctl() the individual paths it had been granted. It wouldn't be able to access devices associated with the host OS mounts, or other non-VM related or non-multipath related block devices. 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
