In the 90s, the school systems were kind of left to fend for themselves. The vast majority of the computers in my schools were systems the area companies were scrapping, but donated them on the way out. A decent part of my programming class was trying to salvage 20 out of 24 systems that a business donated that wouldn't boot. They spent what budget they could on a handful of computers capable of running encarta for the library.

In the 2000s, things started shifting a bit, in a college course we were handed out 'donated' copies of Visual Studio, but the teacher said that's for us but wasn't going to be used for class at all.

Since 2010, things have gotten a bit worrisome as a lot of the big tech have started getting awfully opinionated and wanting to 'help' kids learn to code. Education is all well and good, but when the big corporate interests get actively involved and prescriptive, things drift toward indoctrination more than education.

At least with the 'learn to code', a skill that needed significant develop was being theoretically served, though a lot to be worried about there, with the LLM scenario, it's pretty much just indoctrination. To the extent an LLM works or does not work is not something that takes a significant amount of time to sort out.

As an example, my kid was asked to write a brief thing on what excitingly awesome thing they are looking forward to using AI to do as part of an "AI challenge" at school sponsored by a local tech company. Not to take a critical assessment of things, of evaluating the nuance of benefits and drawbacks, nothing on helping them understand how to best use it, just to blatantly write a puff piece about how awesome AI is/would be for something. Basically soliciting marketing fodder and awarding three kids a couple hundred bucks. It was going to be a grade and so they had to do it and take it seriously..

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.

Because a game optimized version of steam runs games well it can definitely run some janky office software written with weod MS libraries of 20 years ago?

Not sure the one follows the other.

That means 4% are using Linux on the desktop to game.

Obviously less than 5%, but I'm shocked it's only 23% on steak deck.

Steak Deck is great and what got me back into PC gaming. The fact that there are so many desktop users of Linux also tamony is surprising to me.

Somewhere between the 25th and 50th percentile of a stenographer that hasn't pre programmed names.

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

https://en.wikipedia.org/wiki/...

Please take a look at this wikipedia on Limpieza de sangre ("blood purity") from the 1400's and tell me how it fails to qualify as racism.

Wow, the idea that "racism was invented in the 18th century" is the wildest thing I've read in a while. I'm trying to imagine a defense of that statement but I just can't.

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