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