and I think Ubuntu might have io_uring disabled by default, too.
Eh?
Linux s1 6.8.0-57-generic #59-Ubuntu SMP PREEMPT_DYNAMIC Sat Mar 15 17:40:59 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
root@s1:~# lsb_release -sd
No LSB modules are available.
Ubuntu 24.04.2 LTS
root@s1:~# grep URING/boot/config-$(uname -r)
CONFIG_IO_URING=y
root@s1:~# sysctl -a|egrep uring
kernel.apparmor_restrict_unprivileged_io_uring = 0
kernel.io_uring_disabled = 0
kernel.io_uring_group = -1
This has been known since at least 2023. Android doesn't allow apps to use io_uring
Yeah, about that... Android uses their SELinux policy to restrict access to io_uring, so that only trusted system apps can use it. It sounds like some of these system apps do actually benefit from uring and require it. So maybe SELinux is a bad example to be using here, since it doesn't really "break" SELinux. SELinux cannot monitor what uring is doing with granularity. It is up to the admin to choose a proper policy for their SELinux setup. The negligence many people run into is just adding complicated security software and leaving Default system policies that came with your system or apps in place.
ChromeOS has io_uring disabled completely
Google disabled uring in ChromeOS not because of a vulnerability, but because it is Very useful for attackers after exploitation; Most of the attacks would use uring after already compromising the system, and they have not found a means to sandbox uring to mitigate damage following successful attack.
This is why we have things like SELinux to give more fine-grained control over what things running as root can do.
Except when SELinux is not very fine-grained, because SELinux is not necessarily aware of every application and kernel addon. Since SELinux is an extension and not a core part of Linux.. It's kind of the job of a Sysadmin who has installed and chosen to use the SELinux kernel extensions and addon software to make certain that SELinux is aware and compatible of every component of your particular kernel and has suitable policies defined.
Redhat has come to mind as the only distribution that provides SE Linux as available by default, and a huge issue with Redhat is Every 3rd party piece of software you'd actually need to put on your system to use it in the real world tells you to turn off SELinux as a required install step. And even if you don't the admin retains the burden of defining a whole detailed systemwide MAC policy, whereas few bother to do so.
Consider a mail delivery agent. It needs to run as root because it has to be able to change uid/gid to the user that it's delivering mail for to access their mailbox
Except a mail delivery agent doesn't need root at all. SELinux is not necessary. And this software is not designed to require SELinux to be secure or avoid such situations, in the first place. Generally you would design this service to run between dedicated users for example a postfix:mail user and a nobody:nogroup user.
Changing UIDs does not require root access anyways; the privileged portion of your service IF you have one: only requires certain features which can be sectioned using the uid, euid, gid, egid, suid, and sgid, filesystem ACLs, and POSIX Capabilities list of the process.
You can have a single process running as postfix:mail whose sole purpose in life is to Open a user's mailbox file and transfer control over a writable descriptor to that open file using sendmsg() over to the separate MDA process which runs as nobody:nogroup.
You can also have the Mailbox files grant group ownership to the mail group allowing the system mail daemon to write the mailbox file where the MDA program runs as a member of the 'mail' group, and the mail group is granted through Ext3 filesystem ACLs group write access to user mailboxes.
Choose a secure MDA, and the only time a part of it has to run as root is while your system is running its init unit during system boot.