And... I remember the early days of Linux where I ran `make menuconfig` and selected exactly the functionality I wanted in my kernel. I'd... rather not end up back there.
That said a target for an easy win here is RHEL, which compiles a lot of modules into the kernel rather than leaving them as loadable modules, so the mitigation for e.g. copy fail was impossible. Maybe they could do with a few less of those?
Well, because you probably don't, and it's a security risk, so no need to put millions at risk for the benefit of that one person who wants to tinker with packet radio or whatever. Similarly, it would be prudent for distros to not allow autoloading of modules that are extremely niche while giving a simple way to adjust the settings if you want to. God knows they have plenty of GUI configurators and config files already.
No reason why you couldn’t just `dnf install -y kmod-rxrpc` if for whatever reason you need that.
If the kernel modules for esp4, esp6 and rxrpc aren't loaded - how is it that a non-root attacker can cause them to get loaded?
From the sound of it, the same mitigations for Copy Fail 1 are also effective here.
We have forgotten what a distro is, and its modern corruption of the concept is now taken as the definition.
Distributions weren't meant to be competing generic universal bundles of userspace tools in addition to the kernel.
Linux distro maintainers are the most responsible software maintainers on the planet. Their security practices are miles beyond the stupid programming language package managers, they maintain a select list of packages, vet changes, patch bugs, resolve complex packaging issues, backport fixes, use tiered releases, distribute files to global mirrors, and cryptographically validate all files. And might I remind you, they do all this for free.
Today it's 0.1%, tomorrow it might become 100%. User demand is hard to anticipate, so it's reasonable to include small features that don't cost a lot to run by default.
It's not ideal, but you really don't want to prevent user from finishing their task, because maybe then they'll just give you a bad name and switch to another distro.
That's to say, it's not "irresponsible", it's reasonably maximums (at least trying to be).
https://durovscode.com/google-android-security-update-warnin...
The claim is Android is much more secure than other Linux, but if 40% of all Android devices don‘t get a security patch and you can’t even do it yourself I would call the more secure per se.
Hardening is one part of security, patchability another. Android lacks in the latter.
(Of course the problem isn't Android, it's the chipset vendors that the SW depends on. They drop support fast and never give enough info for anyone else to keep things up to date. Also Google.)
No system will stay secure once it does not receive updates. That does not exclude it from being more secure than another system based on security feature merits as long as it does get updated.
>Hardening is one part of security, patchability another. Android lacks in the latter.
That is not an inherent flaw with android but OEM devices shipping modified android they don't bother keeping up to date. Some OEMs are trying to mitigate this by increasing security update support up to 7 years which still is not long enough but also doesn't make them less secure than a desktop that gets updated longer.
What people forget is that not only desktop and mobile phone software is different but also the hardware. If your desktop pc hardware is out of date / EOL nobody cares usually. Meanwhile on a phone this can be a lot more relevant because security expectations and threat models are a lot higher, for example see all the zero/one click compromise headlines.
Having a service that automatically starts and listens on the network is radically different from having a module that a local administrator can load.
If you want to block module loads, you’re one sysctl flag away.
This is a successful local privilege escalation, so local administrator privs were not needed. In default configuration of all distros, apparently.
> If you want to block module loads, you’re one sysctl flag away.
The modules aren't really the point, it's that unnecessary features (to 99% of us?) were accessible by default without privs.
It's not any different from putting an always-running network service behind socket activation instead. The security boundary/risk is nearly identical between the two.
You responded contrasting a network service with an administrator-loadable module.
This is neither of those. It's an LPE, not a remote exploit. It doesn't require an administrator (root) to load anything. In context of this vuln, it's exactly analogous to socket activation. The scope of an LPE vuln is local; yes. What does that have to do with the rest of your comments?
I originally replied to a comment saying "This feels like the practice of Linux distros back in 1999 when they'd ship default installs with dozens of network services exposed to the internet". It is not like that.
Par for the course for HN.
This would reduce the amount of ring 0 code. But I've never seen such advice.
If an attacker manages to do all that, its already bad news for you. Escalation to root with this is the least of your worries at that point.
Like someone else below posted, https://xkcd.com/1200/
People need to understand what the vulnerability actually is before freaking out about it.
Hell, GitHub Actions would do.
We could also wonder why XZ was linked to SSH... But only on systemd-enabled distros (which is a lot of them).
Just... Why?
And then make sure to call to incompetence, instead of malice and say non-sense like "Sure, it only factually affects systemd distros, but this is totally not related to systemd". All I saw though was a systemd backdoor (sorry, exploit).
Now regarding copy.fail that just happened: not all maintainers are irresponsible. And some have, rightfully, bragged that the security measures they preemptively took in their distros made them non vulnerable.
But yup I agree it's madness. Just why. And Ubuntu is a really bad offender: it's as if they did a "yes | .." pipe to configure every single modules as an include directly in the kernel.
"We take security seriously, look we've got the IPsec backdoor (sorry, exploit) modules directly in the kernel". "There's 'sec' in 'IPsec', so we're backdoored (sorry, secure)".