[Animats]

I'm not happy about the entire concept of running user code in the kernel. As a special-purpose hack for servers that do very little else, maybe. As a standard OS feature, it seems to create too big an attack surface. One which has been exploited.[1]

[1] https://www.theregister.com/2022/02/23/chinese_nsa_linux/

[saagarjha]

Your example doesn’t really document an exploit but use of it as a tool in an attack. It’s just an interface they chose to use, not something they broke.

[lcvw]

It requires root to use, if someone has root they’ve already owned your system anyway.

[insanitybit]

The kernel should be considered a tier above root, they shouldn't be considered the same level.

a) Root can be constrained by the kernel via LSM - you can run a program as root and it could be limited to very little given the current set of tools we have.

b) These days unprivileged users can be "root" in their own namespaces, so what "root" is means something very different

[TheJH_]

Re b): Yeah but, like, colloquially "root" means "a process in the init user namespace with all UIDs set to 0 and a full capability mask".

Re a): If you are root in that sense (and haven't been blanket-denied the ability to use capabilities like CAP_SYS_ADMIN by an LSM), and not subject to a strict seccomp policy, then you cannot really in general be securely constrained with LSMs.

The kernel essentially treats CAP_SYS_ADMIN in the init userns as the catch-all for "you have been granted the ability to administer and access anything on the system", for anything that doesn't have a more specific permission and isn't access-controlled by UID. And if you can, like, call swapon() on an arbitrary file to make the kernel swap memory from the whole system into that file of your choice, LSM-enforced security boundaries probably don't work all that well anymore.