On 11/09/2017 17:53, Daniel P. Berrange wrote: > 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 ? The LUNs actually can be identified via /sys/block/dm-NN/slaves (I think), but you cannot find out if it's a mpath device in the first place without a /dev/mapper/control ioctl. >> 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. Yes, that's my reasoning as well. We could (and perhaps should) still look at MCS to block unwanted connections to the socket, though. Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
