On Fri, Apr 24, 2026 at 6:13 PM Jason Gunthorpe <[email protected]> wrote: > > ... I wonder if we are even speaking the same language.
Let's reset the conversation. As I understand it, based on our discussion in this thread and Leon's previous patchsets, the basic idea is to enable LSMs to enforce access control over fwctl requests/commands sent from userspace. I'm going to start with that as a basis. Using the kernel's docs on fwctl, the userspace API appears to consist mostly of ioctls with some basic sysfs interfaces. It looks like we can mostly ignore the sysfs interface and focus on the ioctl side of the API, do you agree? https://docs.kernel.org/userspace-api/fwctl/fwctl.html While normally I would suggest simply using the existing security_file_ioctl() hook, Leon previously mentioned that the hook is too early for fwctl as the userspace copy happens much later. Looking at the code, it appears that the copy happens in fwctl_fops_ioctl() for all fwctl ioctls regardless of the device or ioctl, is that correct? Assuming the above is correct, how about the following LSM hook, called after the copy_struct_from_user() in fwctl_fops_ioctl()? union fwctl_data { struct fwctl_info info; struct fwctl_rpc rpc; } int security_fwctl_ioctl(struct file *filep, unsigned int cmd, union fwctl_data *arg) Where @filep is the file/device being sent the ioctl, @cmd is the ioctl command number (e.g. FWCTL_RPC), and @arg is the copied ioctl data (e.g. ucmd.cmd in fwctl_fops_ioctl). In addition to applying access controls based on the ioctl command number, a capability that already exists via the security_file_ioctl() hook, LSMs could also apply access controls based on the RPC scope as well as any other well defined data in the ioctl payload. I expect most of the existing LSMs would implement callbacks for this new hook with the subject being the process submitting the ioctl, the object being the file/device that is being operated on with the ioctl() call, and the access/privilege/verb/etc. being something along the lines of INFO, RPC_CONFIG, RPC_DEBUG_READ, RPC_DEBUG_WRITE, or RPC_DEBUG_WRITE_FULL. Of course these are just quick examples to demonstrate a point, please don't take those names as hard requirements. Each LSM is free to characterize the access request however they like, in a way that best aligns with their security model. -- paul-moore.com
