Super helpful, thanks Paul! We'll look into this and get back to you
if it doesn't fit our needs.
On Mon, Nov 14, 2022 at 3:31 PM Joel Granados <j.granados@xxxxxxxxxxx> wrote:
>
> On Thu, Nov 10, 2022 at 04:04:46PM -0500, Paul Moore wrote:
> > On Thu, Nov 10, 2022 at 12:54 PM Jeffrey Vander Stoep <jeffv@xxxxxxxxxx> wrote:
> > > On Mon, Nov 7, 2022 at 10:17 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Mon, Nov 7, 2022 at 3:58 PM Gil Cukierman <cukie@xxxxxxxxxx> 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?
> > >
> > > I think there are a few reasons why we want this particular hook.
> > >
> > > 1. It aligns well with how other resources are managed by selinux
> > > where access to the resource is the first control point (e.g. "create"
> > > for files, sockets, or bpf_maps, "prog_load" for bpf programs, and
> > > "open" for perf_event) and then additional functionality or
> > > capabilities require additional permissions.
> >
> > [NOTE: there were two reply sections in your email, and while similar,
> > they were not identical; I've trimmed the other for the sake of
> > clarity]
> >
> > The resources you mention are all objects which contain some type of
> > information (either user data, configuration, or program
> > instructions), with the resulting fd being a handle to those objects.
> > In the case of io_uring the fd is a handle to the io_uring
> > interface/rings, which by itself does not contain any information
> > which is not already controlled by other permissions.
> >
> > I/O operations which transfer data between the io_uring buffers and
> > other system objects, e.g. IORING_OP_READV, are still subject to the
> > same file access controls as those done by the application using
> > syscalls. Even the IORING_OP_OPENAT command goes through the standard
> > VFS code path which means it will trigger the same access control
> > checks as an open*() done by the application normally.
> >
> > The 'interesting' scenarios are those where the io_uring operation
> > servicing credentials, aka personalities, differ from the task
> > controlling the io_uring. However in those cases we have the new
> > io_uring controls to gate these delegated operations. Passing an
> > io_uring fd is subject to the fd/use permission like any other fd.
> >
> > Although perhaps the most relevant to your request is the fact that
> > the io_uring inode is created using the new(ish) secure anon inode
> > interface which ensures that the creating task has permission to
> > create an io_uring. This io_uring inode label also comes into play
> > when a task attempts to mmap() the io_uring rings, a critical part of
> > the io_uring API.
> >
> > If I'm missing something you believe to be important, please share the details.
> >
> > > 2. It aligns well with how resources are managed on Android. We often
> > > do not grant direct access to resources (like memory buffers).
> >
> > Accessing the io_uring buffers requires a task to mmap() the io_uring
> > fd which is controlled by the normal SELinux mmap() access controls.
> >
> > > 3. Attack surface management. One of the primary uses of selinux on
> > > Android is to assess and limit attack surface (e.g.
> > > https://twitter.com/jeffvanderstoep/status/1422771606309335043) . As
> > > io_uring vulnerabilities have made their way through our vulnerability
> > > management system, it's become apparent that it's complicated to
> > > assess the impact. Is a use-after-free reachable? Creating
> > > proof-of-concept exploits takes a lot of time, and often functionality
> > > can be reached by multiple paths. How many of the known io_uring
> > > vulnerabilities would be gated by the existing checks? How many future
> > > ones will be gated by the existing checks? I don't know the answer to
> > > either of these questions and it's not obvious. This hook makes that
> > > initial assessment simple and effective.
> >
> > It should be possible to deny access to io_uring via the anonymous
> > inode labels, the mmap() controls, and the fd/use permission. If you
> > find a way to do meaningful work with an io_uring fd that can't be
> > controlled via an existing permission check please let me know.
>
> Also interested in a more specific case. Sending reply so I get added to
> the group response.
> >
> > --
> > paul-moore.com
