Re: [RFC 1/1] Use ioctl selinux callback io_uring commands that implement the ioctl op convention

[Paul Moore <paul@paul-moore.com>]

On Thu, Nov 17, 2022 at 4:40 AM Joel Granados <j.granados@samsung.com> wrote:
> On Wed, Nov 16, 2022 at 02:21:14PM -0500, Paul Moore wrote:

...

> > * As we discussed previously, the real problem is the fact that we are
> > missing the necessary context in the LSM hook to separate the
> > different types of command targets.  With traditional ioctls we can
> > look at the ioctl number and determine both the type of
> > device/subsystem/etc. as well as the operation being requested; there
> > is no such information available with the io_uring command
> > passthrough.  In this sense, the io_uring command passthrough is
> > actually worse than traditional ioctls from an access control
> > perspective.  Until we have an easy(ish)[1] way to determine the
> > io_uring command target type, changes like the one suggested here are
> > going to be doomed as each target type is free to define their own
> > io_uring commands.
>
> The only thing that comes immediately to mind is that we can have
> io_uring users define a function that is then passed to the LSM
> infrastructure. This function will have all the logic to give relative
> context to LSM. It would be general enough to fit all the possible commands
> and the logic would be implemented in the "drivers" side so there is no
> need for LSM folks to know all io_uring users.

Passing a function pointer to the LSM to fetch, what will likely be
just a constant value, seems kinda ugly, but I guess we only have ugly
options at this point.  I imagine we could cache the result in the
inode's security blob, assuming the device type remained constant (I
can't think of why it would change); still ugly but at least it
doesn't require multiple indirect calls.

It's probably worth throwing together a quick patch so we can discuss
this further.

--
paul-moore.com