Message-ID: <CABXk95ChjusTneWJgj5a58CZceZv0Ay-P-FwBcH2o4rO0g2Ggw@mail.gmail.com>
Date:   Thu, 10 Nov 2022 18:54:00 +0100
From:   Jeffrey Vander Stoep <jeffv@...gle.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Gil Cukierman <cukie@...gle.com>, 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

Hi Paul,

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.
2. It aligns well with how resources are managed on Android. We often
do not grant direct access to resources (like memory buffers). For
example, a single domain on Android manages the loading of all bpf
programs and the creation of all bpf maps. Other domains can be
granted access to these only once they're created. We can enforce base
properties with MAC, while allowing the system to manage and grant
access to resources at run-time via DAC (e.g. using Android's
permission model). This allows us to do better management and
accounting of resources.
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. I believe some of them
currently are exploitable without any selinux permissions. But in any
case, this hook makes that initial assessment simple and effective.

On Mon, Nov 7, 2022 at 10:17 PM Paul Moore <paul@...l-moore.com> wrote:
>
> 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?


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.
2. It aligns well with how resources are managed on Android. We often
do not grant direct access to resources (like memory buffers). For
example, a single domain on Android manages the loading of all bpf
programs and the creation of all bpf maps. Other domains can be
granted access to these only once they're created. We can enforce base
properties with MAC, while allowing the system to manage and grant
access to resources at run-time via DAC (e.g. using Android's
permission model). This allows us to do better management and
accounting of resources.
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.
>

>
> --
> paul-moore.com

Powered by blists - more mailing lists