public inbox for [email protected]
 help / color / mirror / Atom feed
From: Joel Granados <[email protected]>
To: <[email protected]>, <[email protected]>, <[email protected]>,
	<[email protected]>
Cc: <[email protected]>,
	<[email protected]>,
	"Joel Granados" <[email protected]>
Subject: [RFC 0/1] RFC on how to include LSM hooks for io_uring commands
Date: Wed, 16 Nov 2022 13:50:50 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: CGME20221116125430eucas1p2f2969a4a795614ce3b8c06f9ea3be36f@eucas1p2.samsung.com

The motivation for this patch is to continue the discussion around how to
include LSM callback hooks in the io_uring infrastructure. To begin 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 :)

You are very welcome to comment on the patch, but I have specific questions
in mind:

1. The nvme io_uring are governed by ioctl numbers. In this patch I have
passed this number directly to the ioctl_has_perm function in selinux. For
the io_uring commands that follow such a pattern, is it enough to forward
the call? or do we need to plumb something else? @Paul: really interested
in hearing your thoughts.

2. Could we use something similar for commands that are not structured as
an ioctl? Does ublk structure its commands after ioctl, or does it use
another system? @David would like to hear your thoughts on
this.

3. Finally, Is there anything preventing us from gathering all these
io_uring commands under a common LSM infrastructure like the one that
already exists for ioctl?

Comments are greatly appreciated

Joel Granados (1):
  Use ioctl selinux callback io_uring commands that implement the ioctl
    op convention

 security/selinux/hooks.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

-- 
2.30.2


       reply	other threads:[~2022-11-16 12:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20221116125430eucas1p2f2969a4a795614ce3b8c06f9ea3be36f@eucas1p2.samsung.com>
2022-11-16 12:50 ` Joel Granados [this message]
     [not found]   ` <CGME20221116125431eucas1p1dfd03b80863fce674a7c662660c94092@eucas1p1.samsung.com>
2022-11-16 12:50     ` [RFC 1/1] Use ioctl selinux callback io_uring commands that implement the ioctl op convention Joel Granados
2022-11-16 17:38       ` Kanchan Joshi
2022-11-16 19:21         ` Paul Moore
2022-11-17  9:40           ` Joel Granados
2022-11-17 22:10             ` Paul Moore
2022-11-21 19:53               ` Luis Chamberlain
2022-11-21 21:05                 ` Paul Moore
2022-11-22 11:18                   ` Joel Granados
2022-11-22 14:04                   ` Ming Lei
2022-11-28 10:13                     ` Joel Granados
2022-11-28 10:59                       ` Ming Lei
2022-11-22 11:15                 ` Joel Granados
2022-11-17  9:25         ` Joel Granados

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox