On Mon, Sep 11, 2017 at 05:47:28PM +0200, Paolo Bonzini wrote: > On 11/09/2017 17:33, Daniel P. Berrange wrote: > > On Mon, Sep 11, 2017 at 05:27:20PM +0200, Paolo Bonzini wrote: > >> On 11/09/2017 17:23, Daniel P. Berrange wrote: > >>>> 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. > >> > >> Sure, but those capabilities let you do a lot of nasty things > >> indirectly, even within the constraints of the SELinux policy. > >> > >> For example, if you are able to reconfigure device mapper, you can > >> convince the kernel to write to any block device---even if you cannot > >> open it. IDWEFAL (I don't write exploits for a living) but I'm sure > >> that's just scraping the surface. > > > > Surely we would not write an SELinux policy that allows this daemon > > to reconfigure device mapper. > > > > IIUC, all this daemon should need is the ability to request persistent > > reservations on the individual paths associated with the mpath device. > > > > Is it not possible to write a SElinux policy which allows that, without > > also allowing reconfiguration of device mapper. > > As far as I know, querying and reconfiguring the device mapper are both > done with ioctls on /dev/mapper/control, and both require CAP_SYS_ADMIN. > > Maybe future versions of Linux could change it to require CAP_SYS_ADMIN > only for reconfiguration, so that the PR helper daemon does not require > the capability anymore. However, that would be independent from > SELinux, which only controls "ioctl" access without finer-grain choice > of which ioctls to allow. I don't suppose that the LUNS behind a mpath device end up being surface in /sys/block anywhere do they ? > I understand that you want to protect in depth, but unfortunately this > only works if all layers are aware of SELinux. Luckily the daemon is > much, much smaller than QEMU, and so is the attack surface. It would be ok if we think its possible to lock it down later (once any needed kernel enhancements are developed), without having to change the interaction between QEMU / libvirt / helper daemon. I'm beginning to feel that is ok. 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
