lkml.org 
[lkml]   [2022]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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@paul-moore.com> wrote:
    >
    > On Mon, Nov 7, 2022 at 3:58 PM Gil Cukierman <cukie@google.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

    \
     
     \ /
      Last update: 2022-11-10 18:54    [W:3.729 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site