[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhTLBWkw2XzqdFx1LFVKDtaAL2pEfsmm+LEmS0OWM1mZgA@mail.gmail.com>
Date: Mon, 7 Nov 2022 16:13:25 -0500
From: Paul Moore <paul@...l-moore.com>
To: Gil Cukierman <cukie@...gle.com>
Cc: Jens Axboe <axboe@...nel.dk>,
Pavel Begunkov <asml.silence@...il.com>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Stephen Smalley <stephen.smalley.work@...il.com>,
Eric Paris <eparis@...isplace.org>, kernel-team@...roid.com,
linux-kernel@...r.kernel.org, io-uring@...r.kernel.org,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH v1 0/2] Add LSM access controls for io_uring_setup
On Mon, Nov 7, 2022 at 3:58 PM Gil Cukierman <cukie@...gle.com> 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
Powered by blists - more mailing lists