On 11/27/2017 02:29 PM, Daniel P. Berrange wrote: > On Mon, Nov 27, 2017 at 02:01:06PM +0100, Paolo Bonzini wrote: >> On 27/11/2017 13:57, Daniel P. Berrange wrote: >>>> Got it. My problem here is that ioctl permission might be too strict. >>>> One use case for the helper is to bypass the ioctl permission, and only >>>> grant SCSI passthrough access for the specific case of persistent >>>> reservation commands. Would it make sense to also allow e.g. "lock" >>>> (and would it pass the SELinux policy)? >>> When I write "...ioctl perm..." I use that just as a short cut to represent >>> whatever SELinux access vector would be checked if QEMU were to do the SCSI >>> PR calls itself. The access vector permission bits are defined in the policy >>> file, and in the auto-generated header file /usr/include/selinux/av_permissions.h >>> >>> AFAICT, there's only a coarse COMMON_FILE_IOCTL access vector defined, nothing >>> on the level of individual ioctl commands. So, yes, the MAC policy check >>> would allow other ioctl commands to be run, aside from those required for >>> persistent reservations. We just have to rely on the PR helper code for >>> that restriction. >> >> But can you also test _more_ permissions if you want? So if QEMU passed >> to the helper a file for which it has "lock" but not "ioctl" access, >> would it make sense for the helper to let it through? Together with the >> socket MAC, this should be precise enough. > > Sure, you can check any of the permissions which are defined for the > type of object you've got. The goal is to check permissions which > correspond to actions you're taking on the object. So if you do > something other than just ioctl() on the passed in FD, it would make > sense to check further permissions as appropriate. Just to make sure I understand correctly: the PD passing is done by qemu and not libvirt, right? Technically, we don't open the disks. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
