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.
Thanks,
Paolo