Hacker News Reader

Comment by poincaredisk | Hacker News Reader

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.

View on HN

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

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

Remember that 10yo crash? Well, I'm going to use a 12yo kernel and complain about it.

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

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%20...

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.

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.

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?

Reply on news.ycombinator.com