[RFC v2 0/1] RFC on how to include LSM hooks for io_uring commands

[Joel Granados <j.granados@samsung.com>]

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