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@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. 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
