4 ms·

I'd like to use io_uring, but as long as it bypasses seccomp it should be disabled whenever seccomp is in use. As such, I use epoll, and find it annoying when k

I'd like to use io_uring, but as long as it bypasses seccomp it should be disabled whenever seccomp is in use. As such, I use epoll, and find it annoying when kernel APIs like ublk require io_uring. The places I'd want to use ublk are inside sandboxes using seccomp. Given that container runtimes, hardened kernels, chromeos, etc., disable io_uring, using it means needing an epoll fallback anyways, so might as well just use epoll and not maintain two async backends for your application.

poincaredisk 2y ago
Is there a specific io_uring opcode you would like disabled in your sandboxes? It's not like io_uring is a complete seccomp bypass, just another syscall that provides an alternative way to do many things. I doubt you block "read" or "accept" in docker, for example. You can't execute a sysctl or mount a filesystem using io_uring, which are things that are actually blocked in Docker by default. edit: on the other hand, a good reason to disable uring in containers is that it's infested with vulnerabilities. It's new, complex, and does a whole lot of things - all of which make serious security bugs there quite common right now.
- accelbred 2y ago
  Out of current ones, at a quick glance: connect, openat, openat2, renameat, mkdirat, and bind. More importantly, I'd like to block any opcode I haven't whitelisted, even when my software runs on future kernels with more opcodes available. Now that I think about it, how does io_uring interact with landlock?
- ibotty 2y ago
  It's not only potentially infested with vulnerabilities. It's also not possible to filter io_uring using seccomp at all. So if you allow io_uring, you allow all that is possible with it.
- JoshTriplett 2y ago
  > infested with vulnerabilities Current io_uring is not particularly prone to vulnerabilities. The original version of it had a design that often led to them (a kernel thread doing operations on behalf of the process and not always remembering to set the appropriate privileges), but it no longer uses that design, and the current design is much more resilient. Unfortunately, the original design led to a reputation that it's still trying to shake.
  - quotemstr 2y ago
    > Current io_uring is not particularly prone to vulnerabilities The tech industry: launch early! Develop in public! Many eyes make all bugs shallow! Also the tech industry: we will never forgive you for that one segfault you had ten years ago.
    - dietr1ch 2y ago
      Remember that 10yo crash? Well, I'm going to use a 12yo kernel and complain about it.
      - deleted 2y ago
        [deleted]
    - poincaredisk 2y ago
      Excuse me? Io_uring is by far the most often exploited syscall on modern day Linux. Most often exploited subsystem even. https://www.phoronix.com/news/Google-Restricting-IO_uring https://www.phoronix.com/news/Google-Restricting-IO_uring
      - JoshTriplett 2y ago
        That's a lot like saying "the syscall interface is the most exploited interface to the kernel". io_uring is an entire syscall interface itself; the right point of comparison would be "every other syscall". How do the exploits for io_uring compare to the exploits for the rest of the kernel? https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22linux%20kernel%22 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22linux%20...
  - poincaredisk 2y ago
    https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring 20 CVEs in 2024. Yes, some of them are not (exploitable) vulnerabilities, probably, because Linux CNA is being difficult. But many of them are, just ctrl+f privilege.
samlightfoot 2y ago
https://github.com/containerd/containerd/issues/9048 https://github.com/containerd/containerd/issues/9048
fulafel 2y ago
Does this mean you shouldn't use it in containers? edit: it does seem it is disabled there now: https://github.com/containerd/containerd/pull/9320 https://github.com/containerd/containerd/pull/9320 (thanks to sibling comment for an adjancent link)
- cmrdporcupine 2y ago
  Yeah I had code at one point in my hobby project that used io_uring and it stopped working in docker without overriding security restrictions. Unfortunately decided it's not worth it.
JoshTriplett 2y ago
ublk, specifically, is something I'd expect to be primarily used in privileged contexts anyway, because the primary use of the resulting block device is to mount it, which requires privileges for most interesting filesystems. If you want an unprivileged mechanism, you may be interested in the upcoming uring-accelerated FUSE support. For other uses, uring has a "restriction" mechanism that does part of what you want. See REGISTER_RESTRICTIONS in the documentation. Any process that's setting up its own seccomp restrictions can also set up a uring with restrictions, limiting the opcodes it can use. That said, that mechanism would benefit from a way to apply such restrictions to a process that isn't doing the setup itself, such as when setting up seccomp restrictions on a container or daemon. For instance, a way to set restrictions on all rings created by child processes, or a way for seccomp to enforce that any uring created has restrictions applied to it.
- quotemstr 2y ago
  > For instance, a way to set restrictions on all rings created by child processes, or a way for seccomp to enforce that any uring created has restrictions applied to it. SELinux or your favorite MAC is there to solve this exact problem.
- haberman 2y ago
  > you may be interested in the upcoming uring-accelerated FUSE support. Do you have a reference for this? What is the anticipated timeframe?
  - JoshTriplett 2y ago
    https://lore.kernel.org/io-uring/20241209-fuse-uring-for-6-10-rfc4-v8-0-d9f9f2642be3@ddn.com/T/#m95a91425942749be16a45004ad42077622561028 https://lore.kernel.org/io-uring/20241209-fuse-uring-for-6-1... I don't know when it'll be merged, but it seems like it's getting close to ready.
- accelbred 2y ago
  The main problem I have with fuse is inotify not working. If inotify just worked for fuse, I'd just use it. Ideally I could just run the software in a mount namespace with a fuse fs, but I need inotify. I mainly was trying to use ublk to implement a sort of fuse like thing with the kernel handling the fs and thus having inotify support.
quotemstr 2y ago
> find it annoying when kernel APIs like ublk require io_uring Good. That's a forcing function for making io_uring work in your environment. > bypasses seccomp Seccomp sucks. We shouldn't be enforcing security by filtering system calls, the set of which will grow forever, but instead by describing access control rules on objects, e.g. with SELinux. If your security policy is that your sandbox should be able to read from some file but not write to it, you should do that with real MAC, which applies to all operations , il_uring included. You shouldn't just filter read(2) and write(2) in particular. We shouldn't hold back evolution in systems interfaces because some people are stuck on bad ways of doing things and won't move.
- accelbred 2y ago
  Since when can you use a MAC as an unprivileged user on an arbitrary distro?
  - burch45 2y ago
    Parent is referring to https://en.m.wikipedia.org/wiki/Mandatory_access_control https://en.m.wikipedia.org/wiki/Mandatory_access_control As opposed to https://en.m.wikipedia.org/wiki/Medium_access_control https://en.m.wikipedia.org/wiki/Medium_access_control
    - deleted 2y ago
      [deleted]
    - fulafel 2y ago
      Not necessarily, how do I use SELinux as a unprivileged user on eg Debian?
- immibis 2y ago
  seccomp is a mitigation. Once you have already been exploited, if further escalation is prevented by seccomp, or ASLR, or NX stack, or ....... then you got lucky.
- fulafel 2y ago

poincaredisk 2y ago

Is there a specific io_uring opcode you would like disabled in your sandboxes? It's not like io_uring is a complete seccomp bypass, just another syscall that provides an alternative way to do many things. I doubt you block "read" or "accept" in docker, for example. You can't execute a sysctl or mount a filesystem using io_uring, which are things that are actually blocked in Docker by default. edit: on the other hand, a good reason to disable uring in containers is that it's infested with vulnerabilities. It's new, complex, and does a whole lot of things - all of which make serious security bugs there quite common right now.

accelbred 2y ago
Out of current ones, at a quick glance: connect, openat, openat2, renameat, mkdirat, and bind. More importantly, I'd like to block any opcode I haven't whitelisted, even when my software runs on future kernels with more opcodes available. Now that I think about it, how does io_uring interact with landlock?
ibotty 2y ago
It's not only potentially infested with vulnerabilities. It's also not possible to filter io_uring using seccomp at all. So if you allow io_uring, you allow all that is possible with it.
JoshTriplett 2y ago
> infested with vulnerabilities Current io_uring is not particularly prone to vulnerabilities. The original version of it had a design that often led to them (a kernel thread doing operations on behalf of the process and not always remembering to set the appropriate privileges), but it no longer uses that design, and the current design is much more resilient. Unfortunately, the original design led to a reputation that it's still trying to shake.
- quotemstr 2y ago
  > Current io_uring is not particularly prone to vulnerabilities The tech industry: launch early! Develop in public! Many eyes make all bugs shallow! Also the tech industry: we will never forgive you for that one segfault you had ten years ago.
  - dietr1ch 2y ago
    Remember that 10yo crash? Well, I'm going to use a 12yo kernel and complain about it.
    - deleted 2y ago
      [deleted]
  - poincaredisk 2y ago
    Excuse me? Io_uring is by far the most often exploited syscall on modern day Linux. Most often exploited subsystem even. https://www.phoronix.com/news/Google-Restricting-IO_uring https://www.phoronix.com/news/Google-Restricting-IO_uring
    - JoshTriplett 2y ago
      That's a lot like saying "the syscall interface is the most exploited interface to the kernel". io_uring is an entire syscall interface itself; the right point of comparison would be "every other syscall". How do the exploits for io_uring compare to the exploits for the rest of the kernel? https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22linux%20kernel%22 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22linux%20...
- poincaredisk 2y ago
  https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring 20 CVEs in 2024. Yes, some of them are not (exploitable) vulnerabilities, probably, because Linux CNA is being difficult. But many of them are, just ctrl+f privilege.

samlightfoot 2y ago

https://github.com/containerd/containerd/issues/9048 https://github.com/containerd/containerd/issues/9048

fulafel 2y ago

Does this mean you shouldn't use it in containers? edit: it does seem it is disabled there now: https://github.com/containerd/containerd/pull/9320 https://github.com/containerd/containerd/pull/9320 (thanks to sibling comment for an adjancent link)

cmrdporcupine 2y ago
Yeah I had code at one point in my hobby project that used io_uring and it stopped working in docker without overriding security restrictions. Unfortunately decided it's not worth it.

JoshTriplett 2y ago

ublk, specifically, is something I'd expect to be primarily used in privileged contexts anyway, because the primary use of the resulting block device is to mount it, which requires privileges for most interesting filesystems. If you want an unprivileged mechanism, you may be interested in the upcoming uring-accelerated FUSE support. For other uses, uring has a "restriction" mechanism that does part of what you want. See REGISTER_RESTRICTIONS in the documentation. Any process that's setting up its own seccomp restrictions can also set up a uring with restrictions, limiting the opcodes it can use. That said, that mechanism would benefit from a way to apply such restrictions to a process that isn't doing the setup itself, such as when setting up seccomp restrictions on a container or daemon. For instance, a way to set restrictions on all rings created by child processes, or a way for seccomp to enforce that any uring created has restrictions applied to it.

quotemstr 2y ago
> For instance, a way to set restrictions on all rings created by child processes, or a way for seccomp to enforce that any uring created has restrictions applied to it. SELinux or your favorite MAC is there to solve this exact problem.
haberman 2y ago
> you may be interested in the upcoming uring-accelerated FUSE support. Do you have a reference for this? What is the anticipated timeframe?
- JoshTriplett 2y ago
  https://lore.kernel.org/io-uring/20241209-fuse-uring-for-6-10-rfc4-v8-0-d9f9f2642be3@ddn.com/T/#m95a91425942749be16a45004ad42077622561028 https://lore.kernel.org/io-uring/20241209-fuse-uring-for-6-1... I don't know when it'll be merged, but it seems like it's getting close to ready.
accelbred 2y ago
The main problem I have with fuse is inotify not working. If inotify just worked for fuse, I'd just use it. Ideally I could just run the software in a mount namespace with a fuse fs, but I need inotify. I mainly was trying to use ublk to implement a sort of fuse like thing with the kernel handling the fs and thus having inotify support.

quotemstr 2y ago

> find it annoying when kernel APIs like ublk require io_uring Good. That's a forcing function for making io_uring work in your environment. > bypasses seccomp Seccomp sucks. We shouldn't be enforcing security by filtering system calls, the set of which will grow forever, but instead by describing access control rules on objects, e.g. with SELinux. If your security policy is that your sandbox should be able to read from some file but not write to it, you should do that with real MAC, which applies to all operations , il_uring included. You shouldn't just filter read(2) and write(2) in particular. We shouldn't hold back evolution in systems interfaces because some people are stuck on bad ways of doing things and won't move.

accelbred 2y ago
Since when can you use a MAC as an unprivileged user on an arbitrary distro?
- burch45 2y ago
  Parent is referring to https://en.m.wikipedia.org/wiki/Mandatory_access_control https://en.m.wikipedia.org/wiki/Mandatory_access_control As opposed to https://en.m.wikipedia.org/wiki/Medium_access_control https://en.m.wikipedia.org/wiki/Medium_access_control
  - deleted 2y ago
    [deleted]
  - fulafel 2y ago
    Not necessarily, how do I use SELinux as a unprivileged user on eg Debian?
immibis 2y ago
seccomp is a mitigation. Once you have already been exploited, if further escalation is prevented by seccomp, or ASLR, or NX stack, or ....... then you got lucky.
fulafel 2y ago