Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of.
You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to hide most of the kernel. But you really have to know what you're doing and proper security hardening will break a lot of software. To get a basic level of security, you have to disable anything with the letters "BPF", hide all virtual filesystems like /proc, /sys, disable io_uring and remove every CONFIG_* you see until something stops working. Some subsystems seem more vulnerable than others (ironically netfilter seems to be a steady source of vulnerabilities).
When quoting kernel CVEs as evidence as signs of insecurity, especially so seemingly authoritatively, please make sure you're informed about how what Linux kernel CVEs mean.
A CVE (for any product) does not automatically mean there is actually a vulnerability there or even if one is exploitable unless explicitly noted (in the CVE or credibly by someone else). Proof of concepts, reproducibility or even any kind of verification are not a part of the CVE process.
For the Linux kernel in particular, the CVE process is explicitly to be "overly cautious" [1]. In practice, this means the Linux security team requests a CVE for anything that has a mere whiff of being theoretically exploitable. Of course that doesn't mean that the bug that was fixed was actually exploitable, not even theoretically but certainly not in practice.
As a result, you can't use CVEs reported by the Linux kernel to make claims about the (lack of) practical security of any Linux system, including your desktop. The CVEs reported by the Linux kernel are there to notify you to very well informed users of the kernel to do further risk assessments, not to be taken at face value as a sign of insecurity. [The latter is true for the entire CVE system - they're not to be taken at face value as signs something is wrong. But it's especially true for the kernel.]
After the Linux Foundation became a CNA (CVE Numbering Authority), it started issuing CVEs for a broad range of "vulns", such as local denial-of-service, memory errors with no viable exploit path, and logic flaws lacking meaningful security implications.
Looking at the raw number of CVEs is not very meaningful
The way I deal with this at work is: we both work for a person who can fire us for looking at them funny. The threat of dismissal is sufficient for us to expect our peers to be rude neighbors but not criminal ones. If the divisions get big enough that this gets blurry, well then it’s simple enough to ask for private VMs/separate Kube clusters. The Conway’s Law aspects of server maintenance cycles when you report to separate directors/VPs is self evident.
And of course collocating different classes of work can lead to a bug in a low priority task taking down a high priority one. So those also shouldn’t run in the same partition. Once you’ve taken both of those into account, you’ve already added some security in depth. It’s hard even to escalate a remote exploit into a privilege escalation into attacking a more lucrative neighbor.
Yet people use container based isolation all the time in practice and the sky doesn't fall.
Also, every security domain in an Android systems shares a kernel, yet Android is one of the most secure systems out there. Sure, it uses tons of SELinux, but so what? It still has a shared kernel, and a quite featureful one at that.
I don't buy the idea that we can't do intra-kernel security isolation and so we shouldn't care about local privilege escalation.
It's incredible to me that sudo has that many LoC. I'd assume it would just ask the OS to execute something without restrictions, not have any logic to do so itself.
This is yet another case where my policy of stripping out unnecessary dependencies has paid off. thunar-volman and kde solid both pull in udisks by default but back in 2017 I started maintaining a fork of the default Gentoo ebuild to eliminate the dependency on udisks. The thunar-volman case is a great example of why Gentoo use flags are useful no only for customizing a system but for security by making it easier to reduce the attack surface by disabling features that upstreams leave enabled by default.
As someone who has been using linux quite happily on the desktop for more than 20 years now, I have to say it remains an eternal experiment, feature wise as well as security wise.
I use both privately and professionally and while I accept that security-wise (even with selinux) they feel lacking, feature-wise they far exceed Windows I use as my other is except in gaming experience.
I wish I had something like GrapheneOS on desktops (yes I know about Qubes)
Re:"Eternal experiment"... have you seen Windows 11? Or even 10? The devs can't keep their hands off of the thing, changing, breaking and fixing every component every few months.
Let us not pretend other OS are flawless as well. Microsoft is constantly patching and Apple has been the source of so many hacks that thousands of VIPs were affected and a person was murdered.
We're talking about a local privilege escalation here.
That assumes:
1) Attacker already have an account on the system
2) The app `udisks` is installed on the system.
Everyone is fighting the same battle and it's a good thing. It is happening because the rest of the system is hard enough to attack these days. This is true for all major OS:es.
Only fanboys bend reality to make this into a good-vs-bad argument.
Local root privilege escalation is mostly irrelevant these days. It’s only useful as part of an exploit chain, really. It’s not like shell servers are still around.
Another case of environment variables causing LPE. Wonder if we'll ever end up with something more robust for passing details between processes than parsing ambient settings from strings.
> The Qualys Threat Research Unit (TRU), which discovered and reported both flaws, has also developed proof-of-concept exploits and successfully targeted CVE-2025-6019 to get root privileges on Ubuntu, Debian, Fedora, and openSUSE Leap 15 systems.
The vulnerability affects multiple major distributions including Ubuntu, Fedora, and Debian (though some have already patched it), not just openSUSE as claimed.
It's not something that means anything to the kernel, it's a concept in polkit and the various associated userland authorization frameworks which basically means 'things a user currently sat in front of the machine and logged on should be able to do', which includes things like mounting USB drives (but not in arbitrary places and with arbitrary options) and the like.
Tangent(?) on the SUSE PAM part: I was always tripped up by openSUSE default sudo behavior compared to other dists. Unless run with root, it will prompt you for the password of the target user, not your current one, even when current is allowed by sudoers policy.
So 'sudo -u foo bash' will prompt for the password of user foo, 'sudo bash' will prompt for the root password.
Haven't looked closer on how deep this custom configuration goes but would be nice to not have to carry around actual root password for sudo.
It is still the default but it's also trivial to change, so you don't have to "carry around actual root password" for any longer than it takes to create a dropin in /etc/sudoers.d/ with `Defaults !targetpw; %wheel ALL=(ALL) ALL`
Flaw, bug, and security vulnerability are intermixed in the article. This is a mature field. The word choice should be consistent, and it stinks of poor quality when someone chooses to treat them as if they are technically interchangeable problems.
I don't think so. A security vulnerability is a kind of bug, and a bug is a kind of flaw. Once you've introduced a problem using the most specific terminology, it's OK to refer to it using less specific terminology. It can help you avoid sounding repetitive.
(This reminds me of one of my kids at a very young age. If you said "I like your trousers", she'd reply "they're not trousers, they're jeans". But, of course, jeans are a kind of trousers, and it isn't mandatory to be as specific as possible at all times).
Awww. I was just about to gloat about Slackware avoiding another round of security holes due to its long avoidance of PAM, but it got introduced in 2020. :-(
It looks like some software projects are now entirely reliant upon PAM for authentication and don't support shadow passwords anymore. What a travesty. It's sort of like what happened with Systemd, where so many apps now entirely depend on Systemd, you can't run a Linux desktop without a "fake Systemd" to make things work. (see: Alpine Linux desktop, Slackware desktop)
All of this seems to be due to a kind of creepy crawly takeover of the system components, with new ones designed by enterprise companies and a few highly-opinionated software developers (who work at those companies). They design these components to do a million different things, but they also make them highly coupled and interdependent (which is terrible software design, but standard for enterprise products). This then results in a much more complex system with many more moving parts, and makes breaking it easier.
Since these companies hold sway over the most popular Linux distros with the most users, when they make a radical change, everybody else has to adopt it, just like with the browser world. Powerful incumbents exert an unfair (and unhealthy) amount of influence on our environment.
If you went back to a distro from 20 years ago, there really should only be a couple components: The X ecosystem (kernel drivers, userland drivers, rendering libraries), a console login program, a tty manager, a wifi manager, and, well... i'm struggling to think of anything else you need [after the system has booted]. Kernel drivers used to make up 90% of the hardware interfaces. Originally you just wrote to a device file for things like sound, printing, etc. It was an extremely simple system and it worked very well.
Today you have 80 different daemons all running at the same time in order for the system to work at all. Event buses, policy engines, management frameworks, a couple dozen libraries, and multiple layers of components to do something as simple as run a graphical app in a windowed environment. Is this all necessary? Clearly not, as we did without all this crap 20 years ago. Somebody screwed the pooch on system design.
Luckily, it's Linux, so nobody is forcing us to use all this shit. We can just start over with a new, much simpler system (and try hard as hell to avoid second system effect)
And those 80 daemons are started via various systemd and dbus interfaces, and some via other means. If you have a daemon disruptive to your session (like ibus overriding the effect of setxkbmap in a i3 session), and you want to disable it... good luck with finding out what started it.
As vanilla Arch is sort of a meta-distro, it would largely depend upon what the user chose to install and use. For any one of the many spins of Arch, maybe? But one would need to audit each individually.
PhilipRoman|8 months ago
You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to hide most of the kernel. But you really have to know what you're doing and proper security hardening will break a lot of software. To get a basic level of security, you have to disable anything with the letters "BPF", hide all virtual filesystems like /proc, /sys, disable io_uring and remove every CONFIG_* you see until something stops working. Some subsystems seem more vulnerable than others (ironically netfilter seems to be a steady source of vulnerabilities).
DCKing|8 months ago
When quoting kernel CVEs as evidence as signs of insecurity, especially so seemingly authoritatively, please make sure you're informed about how what Linux kernel CVEs mean.
A CVE (for any product) does not automatically mean there is actually a vulnerability there or even if one is exploitable unless explicitly noted (in the CVE or credibly by someone else). Proof of concepts, reproducibility or even any kind of verification are not a part of the CVE process.
For the Linux kernel in particular, the CVE process is explicitly to be "overly cautious" [1]. In practice, this means the Linux security team requests a CVE for anything that has a mere whiff of being theoretically exploitable. Of course that doesn't mean that the bug that was fixed was actually exploitable, not even theoretically but certainly not in practice.
As a result, you can't use CVEs reported by the Linux kernel to make claims about the (lack of) practical security of any Linux system, including your desktop. The CVEs reported by the Linux kernel are there to notify you to very well informed users of the kernel to do further risk assessments, not to be taken at face value as a sign of insecurity. [The latter is true for the entire CVE system - they're not to be taken at face value as signs something is wrong. But it's especially true for the kernel.]
[1]: https://docs.kernel.org/process/cve.html#process
NicolaiS|8 months ago
Looking at the raw number of CVEs is not very meaningful
hinkley|8 months ago
And of course collocating different classes of work can lead to a bug in a low priority task taking down a high priority one. So those also shouldn’t run in the same partition. Once you’ve taken both of those into account, you’ve already added some security in depth. It’s hard even to escalate a remote exploit into a privilege escalation into attacking a more lucrative neighbor.
stouset|8 months ago
Containers are everywhere.
quotemstr|8 months ago
Also, every security domain in an Android systems shares a kernel, yet Android is one of the most secure systems out there. Sure, it uses tons of SELinux, but so what? It still has a shared kernel, and a quite featureful one at that.
I don't buy the idea that we can't do intra-kernel security isolation and so we shouldn't care about local privilege escalation.
uncircle|8 months ago
crest|8 months ago
jart|8 months ago
pinoy420|8 months ago
pona-a|8 months ago
sudo, another setuid binary with a lot of policy code, has 210 CVEs / 430.150 kLoC = ~0.5 CVE per kLoC.
57.5% of CVEs have a CVSS >= 7, so 0.5 * 0.575 = 0.2875 CVE7/kLoC.
As a back-of-envelope estimate,
bapak|8 months ago
j-krieger|8 months ago
tormeh|8 months ago
Repo here: https://github.com/trifectatechfoundation/sudo-rs
It's permissively licensed, unfortunately. Wonder why. It's not a library. But it ought to improve security in the long run.
tgbugs|8 months ago
hbogert|8 months ago
subscribed|8 months ago
I use both privately and professionally and while I accept that security-wise (even with selinux) they feel lacking, feature-wise they far exceed Windows I use as my other is except in gaming experience.
I wish I had something like GrapheneOS on desktops (yes I know about Qubes)
franga2000|8 months ago
stavros|8 months ago
devnullbrain|8 months ago
So while Windows was letting everyone be root?
yusina|8 months ago
amelius|8 months ago
jpnc|8 months ago
pandemic_region|8 months ago
You just defined 'life' in general.
resource_waste|8 months ago
0points|8 months ago
That assumes:
1) Attacker already have an account on the system
2) The app `udisks` is installed on the system.
Everyone is fighting the same battle and it's a good thing. It is happening because the rest of the system is hard enough to attack these days. This is true for all major OS:es.
Only fanboys bend reality to make this into a good-vs-bad argument.
unknown|8 months ago
[deleted]
sneak|8 months ago
teddyh|8 months ago
simoncion|8 months ago
mkj|8 months ago
hansmayer|8 months ago
rob_c|8 months ago
It's the wrong argument to a tool, but the suid part has nothing to do with environment variables or cleaning the env up.
PLEASE STOP SPREADING FUD.
udev4096|8 months ago
aspenmayer|8 months ago
https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt
shakna|8 months ago
- SUSE Linux Enterprise 15 (Current LTS)
- Debian 12 (Current LTS)
- Ubuntu 24.04 (Current LTS)
... Were you thinking about a different bug...?
ethan_smith|8 months ago
belorn|8 months ago
rcxdude|8 months ago
yrro|8 months ago
baobun|8 months ago
So 'sudo -u foo bash' will prompt for the password of user foo, 'sudo bash' will prompt for the root password.
Haven't looked closer on how deep this custom configuration goes but would be nice to not have to carry around actual root password for sudo.
Arnavion|8 months ago
1970-01-01|8 months ago
gmac|8 months ago
(This reminds me of one of my kids at a very young age. If you said "I like your trousers", she'd reply "they're not trousers, they're jeans". But, of course, jeans are a kind of trousers, and it isn't mandatory to be as specific as possible at all times).
0xbadcafebee|8 months ago
It looks like some software projects are now entirely reliant upon PAM for authentication and don't support shadow passwords anymore. What a travesty. It's sort of like what happened with Systemd, where so many apps now entirely depend on Systemd, you can't run a Linux desktop without a "fake Systemd" to make things work. (see: Alpine Linux desktop, Slackware desktop)
All of this seems to be due to a kind of creepy crawly takeover of the system components, with new ones designed by enterprise companies and a few highly-opinionated software developers (who work at those companies). They design these components to do a million different things, but they also make them highly coupled and interdependent (which is terrible software design, but standard for enterprise products). This then results in a much more complex system with many more moving parts, and makes breaking it easier.
Since these companies hold sway over the most popular Linux distros with the most users, when they make a radical change, everybody else has to adopt it, just like with the browser world. Powerful incumbents exert an unfair (and unhealthy) amount of influence on our environment.
If you went back to a distro from 20 years ago, there really should only be a couple components: The X ecosystem (kernel drivers, userland drivers, rendering libraries), a console login program, a tty manager, a wifi manager, and, well... i'm struggling to think of anything else you need [after the system has booted]. Kernel drivers used to make up 90% of the hardware interfaces. Originally you just wrote to a device file for things like sound, printing, etc. It was an extremely simple system and it worked very well.
Today you have 80 different daemons all running at the same time in order for the system to work at all. Event buses, policy engines, management frameworks, a couple dozen libraries, and multiple layers of components to do something as simple as run a graphical app in a windowed environment. Is this all necessary? Clearly not, as we did without all this crap 20 years ago. Somebody screwed the pooch on system design.
Luckily, it's Linux, so nobody is forcing us to use all this shit. We can just start over with a new, much simpler system (and try hard as hell to avoid second system effect)
Sunspark|8 months ago
capitainenemo|8 months ago
blueflow|8 months ago
tux1968|8 months ago
PAM supports a shadow password file as its default configuration. Did you mean something else?
kmeisthax|8 months ago
[deleted]
icar|8 months ago
BirAdam|8 months ago
unknown|8 months ago
[deleted]
jillesvangurp|8 months ago
fitsumbelay|8 months ago
unknown|8 months ago
[deleted]
neuroelectron|8 months ago
b0a04gl|8 months ago
[deleted]
KingLancelot|8 months ago
[deleted]
charcircuit|8 months ago