3 ms·

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 pr

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.

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.