3 ms·

This isn't a "bypass" (and it certainly isn't "terrifying", as reported on /. and elsewhere). 1. The program can only do what it is permitted to do: io_uring j

This isn't a "bypass" (and it certainly isn't "terrifying", as reported on /. and elsewhere). 1. The program can only do what it is permitted to do: io_uring just reduces the number of system calls required - but since it works on file descriptors, you must have already acquired the fd in the correct mode. 2. Some monitoring systems hook into system calls and report when they are used: io_uring and opcodes mean the program can perform actions without being noticed by these programs... 3. ...which can report on the use of the system calls that set up io_uring access... 4. ...and could report on the resuting I/O by other means. I won’t go so far as to say this is a nothing burger, but it feels close.

yencabulator 1y ago
> io_uring just reduces the number of system calls required - but since it works on file descriptors, you must have already acquired the fd in the correct mode. With the caveat that you can open files through io_uring requests, too: https://www.man7.org/linux/man-pages/man3/io_uring_prep_open.3.html https://www.man7.org/linux/man-pages/man3/io_uring_prep_open... And they might not have traditional FDs: https://lwn.net/Articles/863071/ https://lwn.net/Articles/863071/ But yes, it's bad security architecture (fail-open), not updated fast enough. The real answer is probably something more like Landlock, where it's the kernel's job to understand syscall semantics.
- PeterWhittaker 1y ago
  True, but even those calls require appropriate permissions, and will fail if the program lacks said perms. (Just to emphasize the point that the original article doesn't provide a means of privilege escalation, nor exploit a vulnerability.)