From: Paul Moore <[email protected]>
To: Gil Cukierman <[email protected]>
Cc: Jens Axboe <[email protected]>,
Pavel Begunkov <[email protected]>,
James Morris <[email protected]>,
"Serge E. Hallyn" <[email protected]>,
Stephen Smalley <[email protected]>,
Eric Paris <[email protected]>,
[email protected], [email protected],
[email protected], [email protected],
[email protected]
Subject: Re: [PATCH v1 0/2] Add LSM access controls for io_uring_setup
Date: Mon, 7 Nov 2022 16:13:25 -0500 [thread overview]
Message-ID: <CAHC9VhTLBWkw2XzqdFx1LFVKDtaAL2pEfsmm+LEmS0OWM1mZgA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
On Mon, Nov 7, 2022 at 3:58 PM Gil Cukierman <[email protected]> wrote:
>
> This patchset provides the changes required for controlling access to
> the io_uring_setup system call by LSMs. It does this by adding a new
> hook to io_uring. It also provides the SELinux implementation for a new
> permission, io_uring { setup }, using the new hook.
>
> This is important because existing io_uring hooks only support limiting
> the sharing of credentials and access to the sensitive uring_cmd file
> op. Users of LSMs may also want the ability to tightly control which
> callers can retrieve an io_uring capable fd from the kernel, which is
> needed for all subsequent io_uring operations.
It isn't immediately obvious to me why simply obtaining a io_uring fd
from io_uring_setup() would present a problem, as the security
relevant operations that are possible with that io_uring fd *should*
still be controlled by other LSM hooks. Can you help me understand
what security issue you are trying to resolve with this control?
--
paul-moore.com
next prev parent reply other threads:[~2022-11-07 21:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 20:57 [PATCH v1 0/2] Add LSM access controls for io_uring_setup Gil Cukierman
2022-11-07 20:57 ` [PATCH v1 1/2] lsm,io_uring: add LSM hook " Gil Cukierman
2022-11-07 21:13 ` Paul Moore [this message]
2022-11-10 17:54 ` [PATCH v1 0/2] Add LSM access controls " Jeffrey Vander Stoep
2022-11-10 21:04 ` Paul Moore
[not found] ` <CGME20221114143147eucas1p1902d9b4afc377fdda25910a5d083e3dc@eucas1p1.samsung.com>
2022-11-14 14:31 ` Joel Granados
2022-11-15 5:39 ` Jeffrey Vander Stoep
2023-08-08 20:40 ` Dmytro Maluka
2023-08-09 0:31 ` Paul Moore
2023-08-09 11:21 ` Dmytro Maluka
2023-08-09 14:49 ` Paul Moore
2023-08-09 17:28 ` Dmytro Maluka
2023-08-10 9:08 ` Dmytro Maluka
2023-08-10 12:27 ` Stephen Smalley
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 \
--in-reply-to=CAHC9VhTLBWkw2XzqdFx1LFVKDtaAL2pEfsmm+LEmS0OWM1mZgA@mail.gmail.com \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[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