The motivation for this patch is to continue the discussion around how to include LSM callback hooks in the io_uring infrastructure. This is the second version of the RFC and is meant to elicit discussion. I'll leave general questions and the descriptions of the different approaches. Comments are greatly appreciated Approaches: V2: I add a callback to the file_operations struct that will set a security_uring structure with all the elements needed for LSMs to make a decision. io_uring is still agnostic as it will just pass the callback along and LSM can just focus on getting the data they need in the uring security struct. When security is not defined in CONFIG the security_uring_cmd can just be a noop (or itself be in an ifdef). V1: I take the nvme io_uring passthrough and try to include it in the already existing LSM infrastructure that is there for ioctl. This is far from a general io_uring approach, but its a start :) Questions: 1. Besides what is contained in the patch, would there be something additional to plumb in LSM? 2. Is this general enough to fit all io_uring passthrough commands? 3. I'm trying to separate responsabilities. The LSM folks can take care of LSM stuff and the io_uring users can take care of their specific domain. Does this patch fulfill this? 4. Are there other approaches to solve this problem? Joel Granados (1): Use a fs callback to set security specific data drivers/nvme/host/core.c | 10 ++++++++++ include/linux/fs.h | 2 ++ include/linux/lsm_hook_defs.h | 3 ++- include/linux/security.h | 16 ++++++++++++++-- io_uring/uring_cmd.c | 3 ++- security/security.c | 5 +++-- security/selinux/hooks.c | 16 +++++++++++++++- 7 files changed, 48 insertions(+), 7 deletions(-) -- 2.30.2
