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).
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.
pxeger1 · 4m ago
[delayed]
pinoy420 · 2h ago
Given this. Why is every linux device not rooted then.
b0a04gl · 36m ago
udisks integrates with PAM through 'pam_env', which loads environment variables from hidden files like '~/.pam_environment'. this design assumes user home directories are trustworthy even during privilege escalations. on most distros, udisks runs as root and allows mounting/unmounting actions triggered by users. the attack path here still don't audit pam\_env behavior because it's seen as low risk
neuroelectron · 3m ago
Golden opportunity for bitcoin miners on AWS.
pona-a · 3h ago
udisks, not counting its dependencies, has 265,334 LoC. pmount, in contrast, has 19,978 LoC, or >13x less.
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.
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.
saagarjha · 2h ago
Asking the OS to do something without restrictions is not very difficult; sudo does that by virtue of its existence (it's setuid). The extra code is deciding when not to do that.
quotemstr · 4m ago
The problem isn't even setuid exactly but the size of the TCB. Setuid encourages a design in which tons of stuff that doesn't need to run as root runs as root anyway just because it's part of the same binary that needs elevated privileges. It's a footgun, but one can handle even a footgun safely if you practice trigger discipline and assume every gun is loaded.
Sudo (and other setuid programs) could in principle use privilege separation to punt everything not absolutely essential to an unprivileged context and thereby reduce the size of the TCB.
pona-a · 2h ago
OpenDoas, a portable version of OpenBSD's doas, has 4260 LoC while doing most you'd expect. Sudo just has a lot of policy tools that most don't even know about, but add to its surface area.
puzzlingcaptcha · 47m ago
OpenDoas is used by default by Alpine linux for example.
rcxdude · 2h ago
sudo has a lot of machinery for representing complex policies which involve partial access to elevated (or just different) permissions, and with more conditions than just a correct password for the requesting user. The kernel itself just sees a binary running as root which may drop some of those permissions before starting another process.
(And this isn't even the most arcane part of linux userland authorization and authentication. PAM is by far the scariest bit, very few people understand it and the underlying architecture is kinda insane)
commandersaki · 1h ago
I think it's all the stuff to do with using a shared sudoers across a network of hosts. They could really clean up the language if they removed all of that gunk, as it's not reflective of how sudo is deployed these days.
lukaslalinsky · 25m ago
Even these days, I don't like having deployment SSH keys, or anything of that nature, unless the users are sudo-restricted. You might say that's obsolete in today's world of kubernetes/clouds, but there are many many use cases not met by these things and even for the clouds, someone needs to run them.
bbarnett · 1h ago
There's also full sudo session logging and a logging server now, along with binaries to replay all those logs. Whether those LOC reflect the logging server, I don't know.
It literally replays in the terminal like a movie. It's nice, but I worry too much about the security implications (passwords captured, etc) to roll it out.
edit:
Ah yes, sudoreplay. You can see this video a playback via it. That's not the guy typing, that's sudoreplay time-accurately replaying what happens.
When I'm told my code needs to "just" do X, it is usually the case that it needs to do a bunch of other stuff to enable X.
ikekkdcjkfke · 1h ago
Why does anything at all need to be executed without restrictions though
salawat · 1h ago
Should your calculator ask who you are to compute 2+2? Contrary to popular belief, access control was stapled onto the computation space. There was a time when it was considered an unnecessary extravagance. It only became the night unbuckle mandate that machines give a shit about who you are once we started using computers as the basis of business systems.
Accounts thereafter, ruined everything.
Asooka · 1h ago
There is no such API on Linux, it is accomplished by sudo having the setuid bit set, which instructs the kernel to start it as root regardless of the current user. It's probably one of the worst legacy designs still in use - if any binary has setuid set, it runs as root, no questions asked. Conversely, you also have no way of elevating privileges for a running binary. This really should have been solved decades ago with a robust API for authentication and authorisation of running processes to gain and lose privileges, like what Windows has. Having a filesystem bit grant root privileges to a program is insane. There are probably a dozen CVEs waiting to be discovered with silently corrupting the filesystem and setting that bit on your binary.
SoftTalker · 31m ago
> if any binary has setuid set, it runs as root
More precisely, it runs as the file owner. Which is often root.
j-krieger · 2h ago
I can't for the life of me find a list of 210 sudo CVE's. Are you sure this is correct?
pona-a · 2h ago
I got it from here [0]. I didn't notice it was a keyword search, so it's an overcount. Thanks for correcting me.
Going off its security advisories page [1] and this tracker [2], it seems to be around 43 CVEs, most rated high severity.
So the actual rate would be 43 CVE / 430 kLoC = ~0.01 CVE per kLoC, so ~2.65 CVEs for udisks and ~0.2 for pmount.
I've been loosely involved in setting this up, so I can say a little: The people that funded the initial work wanted it permissively licensed. My (somethwat informed) conjecture is that they rank making things secure - even in closed source apps that now could take the code - higher than barring closed forks. It also tracks with the Rust ecosystem in general - APL or derivates are very common in that ecosystem.
johnisgood · 44m ago
Do they not think that the switching is premature? I am pretty sure the Rust version has a lot of logic bugs that not have yet been found. But then again, it is Ubuntu, I expected nothing better, and I will never touch it, so I am unaffected, thankfully.
faceplanted · 28m ago
> I am pretty sure the Rust version has a lot of logic bugs
What makes you say that? I'm not trying to be argumentative, I'm genuinely interested.
jonathanstrange · 17m ago
Whenever a complex system is rewritten, there are a lot of bugs and regressions in it.
throw0101b · 1h ago
> Some functionality is not supported, such as […] storing config in LDAP using sudoers.ldap, and cvtsudoers.
Well that makes it useless for $WORK (for now), as we use LDAP as our central policy repo (and more generally our user account store). Will have to wait until (at least) that's implemented before we can even consider it.
So it can be used distributed with fewer legal hassles.
stephenr · 1h ago
> It's permissively licensed, unfortunately.
Well damn that's a shame. I just hate it when people let others use their work in a way they choose, that happens to be less restrictive than my own personal choices.
/s of course.
scheeseman486 · 1h ago
Worked out for Linux, which remains a largely open, collaborative ecosystem. Meanwhile all the BSDs are good for are as less-good Linuxes that can be shoved into proprietary products. Google is choking out AOSP, which they can do because of Android's "less restrictive" license.
Copyleft licenses are demonstrably better for open source projects in the long run. We've had enough time to prove that out now.
jcranmer · 44m ago
The success of Linux over BSD has more to do with a lawsuit in the early 90's over whether or BSD infringed on Unix's source code, which made Linux the only viable open source Unix-like operating systems if you had to ask a legal department the question.
Look beyond the OS, and much of the tech stack is dominated by non-copyleft open source projects. Both the major web servers--Apache and nginx--are permissively licensed, for example. Your SSL stacks are largely permissively licensed; indeed, most protocol servers seem to me to largely be permissively licensed rather than copyleft.
And I should also point out a clear example where copyleft has hobbled an ecosystem: Clang and LLVM have ignited a major compiler-based ecosystem of ancillary tools for development such as language servers. The gcc response to this is... to basically do nothing, because tight integration of the compiler into other components might allow workarounds that release the precious goodness of gcc to proprietary software, and Stallman has resisted letting emacs join in this revolution because he doesn't want a dependency on non-copyleft software. An extra cruel irony is that Clang appears to be an existential threat to the proprietary EDG compiler toolchain, which would mean it took a permissive license to do what the goal of the copyleft license was in the first place: kill proprietary software.
Xylakant · 1h ago
I think it's pretty reductive to boil down linux' success to the choice of license. There's governance model, development model, institutional inerta, ... - and the linux ecosystem contains tons of permissively licensed pieces of software, some of which massively contributed to its success (the once-default webserver that came with its own permissive license, the APL). Even the kernel includes APL, BSD-2 Clause and MPL'ed code.
To the contrary, GNU Hurd is GPL'ed and is much less successful than the linux kernel.
wesselbindt · 1h ago
Given that enshittification is a thing, and embrace extend extinguish is a thing, I'm inclined to agree with you there, without the /s.
mkj · 2h ago
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.
Instead of using something standard like environment variables, pam has a special "pam_env" that contains facts about the user session that it apparently trusts. Users can override pam_env settings by writing to hidden file in ~.
So, this exploit chain is more accurately described as "yet another example of utilities inventing new, obscure configuration mechanisms for security-critical settings, allowing policy flaws to remain undetected for a long time".
Running security configuration options through a special snowflake IPC mechanism (instead of keeping them in a file where they could actually be inspected by humans) would only make things worse.
o11c · 20m ago
If they mutated the real environment it could be even worse, since they're still privileged code and there are all sorts of environment variables that libraries read at runtime using `secure_getenv`.
I finally understand why they're trying to deprecate `pam_env`, despite its incredible utility. For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.
mkj · 1h ago
Ok yeah, I had actually misread what the vars were.
But it's the same kind of problem as general environment vars - rather than just a name, maybe it needs metadata of where it came from.
To be clear, I'm talking about the unprivileged to allow_active CVE-2025-6018, not the allow_active to root.
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.
1970-01-01 · 1h ago
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.
gmac · 1h ago
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).
1970-01-01 · 1h ago
Software bug is just one area in the venn diagram of security vulnerability. Include areas outside of this such as insecure default settings, misconfigurations, major design weaknesses, hardware exploitations, etc. and you see my point.
belorn · 2h ago
Could someone describe what 'allow_active' privileges is on Linux?
rcxdude · 2h ago
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.
hbogert · 6h ago
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.
subscribed · 6h ago
That's certainly an interesting standpoint.
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)
mathverse · 2h ago
There is https://grsecurity.net/ but it's not free. It's developed by people with much more experience defending against attackers than all of the other projects combined.
bee_rider · 1h ago
Who are they?
lima · 4h ago
Chromium OS gets very close, they also have fully-functional VM-based isolation for Linux applications with GPU acceleration.
Unfortunately, there's no popular non-Google distro of it.
londons_explore · 2h ago
The fact that Chromium OS has been teetering on the edge of deprecation/merging with Android/Fuchsia for a decade I think has deterred people from building stuff on top of it.
It also seems to have a lot of new code every year for very few new features. It's as if they get every new intern to rewrite a bit of the innards, and then next summer another intern rewrites it again.
p_l · 1h ago
OTOH, it was used for multiple container-optimized distros by now:
First CoreOS, which forked into Flatcar Linux (now funded by Microsoft) and Fedora CoreOS (rewrite from Gentoo/ChromeOS base to Fedora base), and Google's Container-Optimized System (used heavily in Google Kubernetes Engine).
IlikeKitties · 6h ago
> I wish I had something like GrapheneOS on desktops (yes I know about Qubes)
SecureBlue and Kicksecure are the closest equivalents.
arbll · 2h ago
Don't know much about SecureBlue but Kicksecure isn't comparable to Qubes at all. It's a hardened distro, not a way to isolate workloads through virtualisation. Depending on what you're trying to achieve they can both fit but they are fundamentally very different in their approach to security.
IlikeKitties · 2h ago
> I swear to god reading comprehension is approaching zero due to chatgpt.
> I wish I had something like GrapheneOS on desktops
Secureblue is essentially as close to GrapheneOS as Desktop Linux can get. Neither my response nor the original question required qubes comparisons. It was merely mentioned.
> grsecurity® is the only drop-in Linux kernel replacement offering high-performance, state-of-the-art exploit prevention against both known and unknown threats.
While secureblue is a full desktop distro (not just a kernel) that integrates key grapheneos hardening tools like their hardened malloc and forks of their hardened chromium and works with flatpak as a base for hardened application deployment.
grsecurity does literally none of that.
mathverse · 27m ago
Yes grsecurity offers actual hardening instead of touting snakeoil.
IlikeKitties · 6m ago
You are literally saying that hardening the kernel is the same as having the desktop environment hardened and a basis for app isolation. And to add a cherry on top of that both secureblue and kicksecure use almost all the same hardening additions to the linux kernel as grsecurity.
You do not understand what you are talking about because if you did you'd be embarrassed for how braindead your response is.
same! qubes is probably the actual solution for now, but i've seen some grapheneos people work on https://secureblue.dev/ and that seems a lot more "normal"
udev4096 · 5h ago
I have been meaning to try out secureblue and hopefully even run it on production VMs in proxmox. Is it stable yet?
franga2000 · 5h ago
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.
bee_rider · 1h ago
I don’t think we need to “whatabout” Windows. I don’t think anyone would say they are trying too many experiments… actually, Windows feels like it was mostly made by overworked folks doing the bare minimum to not get fired. No time for experiments or caring.
Geezus_42 · 2h ago
Adding ADs to every possible surface, finding new ways to obfuscate built-in spyware
layer8 · 1h ago
Active Directories?
stavros · 6h ago
If you think Linux is an experiment, you should see the other OSes.
ahofmann · 6h ago
I'm pretty sure, that the BSD family is pretty mature and secure. Linux is just good enough for most people.
8fingerlouie · 4h ago
A big part of the difference is that the BSDs are designed by a governing committee. They usually don't have 15 different solutions for the same problem, but instead 2-3 solutions that work well.
Take filesystems, the official filesystems are UFS(1/2) and ZFS. They have GEOM as LVM and LUKS and more.
That being said, the majority of money and development goes into Linux, which by itself may make it a better system (eventually).
Edit: Of course UFS is not deprecated.
gnfargbl · 2h ago
I can't help but make the comparison with cryptographic network protocols, where the industry started with a kitchen-sink approach (e.g. pluggable cipher suites in TLS) and ended up moving towards fixed primitives (e.g. Wireguard mostly uses DJB-originated techniques, take them or leave them).
The general lesson from that seems to be that a simpler, well-understood, well-tested and mostly static attack surface is better than a more complex, more fully-featured and more dynamic attack surface. I wonder whether we'll see a trend towards even more boring Linux distributions which focus on consistency over modernity. I wouldn't complain if we did.
uncircle · 51m ago
> A big part of the difference is that the BSDs are designed by a governing committee
While I cannot agree nor disagree on the quality of BSDs (haven't used one in 20 years), I find it funny that in this case a design by committee is proof of quality.
I guess it's better than design by headless chicken which is how the Linux user-space is developed. Personally, I am a big fan of design by dictatorship, where one guy at the top either has a vision or can reject silly features and ideas with strong-enough words (Torvalds, Jobs, etc.) - this is the only way to create a cohesive experience, and honestly if it works for the kernel, there's no reason it shouldn't work in userspace.
throw0101b · 34m ago
> While I cannot agree nor disagree on the quality of BSDs (haven't used one in 20 years), I find it funny that in this case a design by committee is proof of quality.
I don't think "design" is correct word: organized, managed, or ran perhaps.
> The FreeBSD Project is run by FreeBSD committers, or developers who have direct commit access to the master Git repository.[1] The FreeBSD Core Team exists to provide direction and is responsible for setting goals for the FreeBSD Project and to provide mediation in the event of disputes, and also takes the final decision in case of disagreement between individuals and teams involved in the project.[2]
There is no BDFL, à la Linux or formerly Python: it's a 'board of directors'. Decisions are mostly dispute / policy-focused, and less technical for a particular bit of code.
graemep · 4h ago
> A big part of the difference is that the BSDs are designed by a governing committee. They usually don't have 15 different solutions for the same problem, but instead 2-3 solutions that work well.
The right comparison is not between a particular BSD and Linux, its between a particular BSD and a Linux distro.
jeltz · 4h ago
I feel the BSDs are much more different from each other than the average Linux distros are.
graemep · 2h ago
Average/most popular distros, maybe.
The full range of distros are very different from each other. Consider Void, Alpine, Gentoo, Chimera, NixOS.....
Different C libraries, init systems, different default command line utilities....
anthk · 26m ago
That's nothing. Alpine can run Glibc binaries with compat libraries.
Try running a FreeBSD binary under OpenBSD.
assimpleaspossi · 4h ago
UFS is not deprecated on FreeBSD.
hxorr · 4h ago
I believe it is the default on netBSD
bee_rider · 1h ago
BSD doesn’t count, everybody agrees it is the best OS they aren’t using.
NexRebular · 4h ago
> I'm pretty sure, that the BSD family is pretty mature and secure.
Not to mention illumos-based systems too.
johannes1234321 · 2h ago
I ran Open Solaris for a while on my Laptop and it's quite nice. However the lack of support by practically any software vendor made many things a pain.
Since then even more stuff went to the Web, but I really I doubt Illumos got any extra traction.
NexRebular · 2h ago
Most of our server infrastructure runs on illumos at $work. SmartOS/Triton handles our "cloud" and OmniOS runs our storage. The linux monoculture problem luckily can still be handled with zones and bhyve, and I do trust illumos developers' competence to deliver good quality secure software a lot more than linux developers' as well.
Now if FreeBSD (or indeed illumos) would get CUDA-support we could stop using linux for GPU nodes too.
throw0101b · 1h ago
> Now if FreeBSD (or indeed illumos) would get CUDA-support we could stop using linux for GPU nodes too.
Could you not run Linux CUDA binaries under FreeBSD's Linuxulator?
charcircuit · 5h ago
>is pretty mature and secure
They are still missing something like capability based security like iOS and Android have where apps have to be granted access to use things like files or the camera. It may have been considered secure a couple decades ago, but they have fallen behind the competiton.
wahern · 4h ago
FreeBSD literally has Capsicum: https://en.wikipedia.org/wiki/Capsicum_(Unix) That might be the most pure capability system out of all of them, though it's not something that works without application modification (yet). Android and iOS applications can automatically work with the native capability framework because they rely on higher-level SDK APIs. But AFAIU those capability systems are very coarse-grained, in the sense that it's difficult leverage the capability system internally within a single application. And keeping lower-level APIs (e.g. for C and POSIX filesystem I/O) nominally working (if at all) requires some impure hacks. All of which makes them very similar to FreeBSD Jails or Linux containers in that respect.
I wouldn't consider any of these systems "secure", though, as a practical matter. In terms of preventing a breakout, I'd trust an application on OpenBSD with strict pledge and unveil limits, or a Linux process in a classic seccomp sandbox (i.e. only read, write, and exit syscalls), more than any of those other systems. Maybe Capsicum, too, but I'm not familiar enough with the implementation to know how well it limits kernel code surface area. But any application that can poke at (directly or indirectly) complicated hardware, like the GPU, is highly problematic unless there are proofs of correctness for any series of inputs that can be sent by the process (which I don't think is the case).
8fingerlouie · 4h ago
You can use Jails and limit access to hardware resources for each jail. Still not as dynamic, but will get the job done.
charcircuit · 4h ago
Sure, but this is not done automatically for the user.
bee_rider · 1h ago
For the types of computers BSD is typically run on, just unplug the webcam.
NexRebular · 4h ago
> They are still missing something like capability based security
No, that requires explicit changes by programs to use meaning that malware can ignore it and steal your browser's cookies and take secret photos with your webcam.
NexRebular · 4h ago
So the capability-based security framework is not missing unlike your original statement?
resource_waste · 1h ago
iOS so so insecure that thousands of people have been hacked and at least 1 person was killed.
The last place in security is iOS.
khurs · 6h ago
Including Openbsd?
devnullbrain · 5h ago
>20 years ago
So while Windows was letting everyone be root?
jpnc · 4h ago
That goes for all (active) software really. Otherwise people call it obsolete or abandoned.
amelius · 5h ago
What especially feels like an experiment is container technology.
coderatlarge · 5h ago
how much harder is container escaping compared to vm escaping? i understand that containers are not truly meant to be security boundaries but they are often thought of and even used as such.
fc417fc802 · 5h ago
> how much harder is container escaping compared to vm escaping?
The answer heavily depends on your configuration. Unprivileged with a spartan syscall filter and a security profile is very different than privileged with the GPU bindmounted in (the latter amounts to a chroot and a separate user account).
tetha · 4h ago
Hence if I ever get money for an infrastructure pentest, I want to include a scenario that scares me a bit: The hijacked application server. The pentesters give me a container with whatever tooling they want and a reverse shell and that gets deployed in the dev-infrastructure, once privileged and once unprivileged, both with a few secrets an application server would have. I'd just reuse a deployment config from some job. And then have at it.
And yes, this will most likely be a mess.
arbll · 2h ago
Situational but if you're in default configurations it's comparable. Both will need some form of unknown vuln. It boils down to wether you trust more the linux namespacing logic and container runtime glue or the hypervisor logic.
yusina · 5h ago
Software is rarely "done", so is quite naturally always an evolving experiment of sorts.
resource_waste · 1h ago
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.
danparsonson · 1m ago
What a weird comment - if Apple software had less exploits then the murder would have been averted? And those 'VIPs', whoever they are - would it be less significant if there were normies? I sincerely hope none of my coding mistakes ever causes a VIP to be murdered.
0points · 4h ago
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.
pandemic_region · 6h ago
> I have to say it remains an eternal experiment
You just defined 'life' in general.
sneak · 6h ago
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.
magicalhippo · 6h ago
An exploit chain, like combining it with the PAM issue they mentioned in the very same article, affecting Fedora.
TheDong · 6h ago
The article was about two issues that combine to make a single local-privilege-escalation, so the PAM thing isn't a separate exploit chain, it's just part of getting local root in this vulnerability.
What the parent poster meant is that you first need a way to run arbitrary code before local privilege escalation matters, so the exploit chain has to include _something_ that gets you local code execution.
I tend to agree with the parent poster, for most modern single-user linux devices, local privilege escalation means almost nothing.
Like, I'm the only user on my laptop. If you get arbitrary code execution as my user, you can log my keystrokes, steal my passwords and browser sessions, steal my bitcoin wallet, and persist reasonably well.... and once you've stolen my password via say keylogging me typing `sudo`, you now have root too.
If you have a local privilege escalation too, you still get my passwords, bitcoin wallet, etc, and also uh... you can persist yourself better by injecting malware into sshd or something or modifying my package manager? idk, seems like it's about the same.
worthless-trash · 6h ago
Some services dont run as the same user logging into the laptop.
simoncion · 6h ago
> ...for most modern single-user linux devices, local privilege escalation means almost nothing.
I haven't actually looked at the numbers, but I strongly suspect that it's true that the overwhelming majority of single-user Linux devices out there are Android devices. If that's true, then it's my understanding that Android does bother to fairly properly sandbox programs from each other... so an escalation to root would actually be a significant gain in access.
DaSHacka · 5h ago
Does Android use Udisks? I assumed it did not, due to the difference in architecture over most traditional GNU/Linux desktop systems
simoncion · 5h ago
I have no idea if Android uses udisks. It has been something like a decade since I last looked at 'ps' output on an Android machine, so any information on the topic I might have had has faded away with time.
arbll · 2h ago
this type of exploits are goldmines for attackers, it means they have a window of a few month to years to turn any basic access into root. It doesn't have to be a super complex exploit chain, anyone running wordpress botnets it going to add this to their arsenal
worthless-trash · 6h ago
An attacker doesn't need a shell server to run code locally, you chain it with an exploit to a service and you have root and now have lateral attack capabilities.
It's pretty old and only affects openSUSE, the title is extremely misleading
aspenmayer · 5h ago
> 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.
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)
tux1968 · 2m ago
> reliant upon PAM for authentication and don't support shadow passwords
PAM supports a shadow password file as its default configuration. Did you mean something else?
capitainenemo · 23m ago
devuan also uses a stub fake libsystemd but it really is just a stub to avoid broken calls.
Sunspark · 17m ago
Make BSD great again!
icar · 3h ago
Was Arch ever affected?
BirAdam · 9m ago
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.
charcircuit · 5h ago
Another case of suid causing LPE. When will distros learn that suid needs to be removed or disabled if they want security?
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).
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.
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,
Sudo (and other setuid programs) could in principle use privilege separation to punt everything not absolutely essential to an unprivileged context and thereby reduce the size of the TCB.
(And this isn't even the most arcane part of linux userland authorization and authentication. PAM is by far the scariest bit, very few people understand it and the underlying architecture is kinda insane)
It literally replays in the terminal like a movie. It's nice, but I worry too much about the security implications (passwords captured, etc) to roll it out.
edit:
Ah yes, sudoreplay. You can see this video a playback via it. That's not the guy typing, that's sudoreplay time-accurately replaying what happens.
https://www.youtube.com/watch?v=8XHlowCiLaM
Accounts thereafter, ruined everything.
More precisely, it runs as the file owner. Which is often root.
Going off its security advisories page [1] and this tracker [2], it seems to be around 43 CVEs, most rated high severity.
So the actual rate would be 43 CVE / 430 kLoC = ~0.01 CVE per kLoC, so ~2.65 CVEs for udisks and ~0.2 for pmount.
[0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo
[1] https://www.sudo.ws/security/advisories/
[2] https://security.snyk.io/package/linux/debian%3A10/sudo
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.
I've been loosely involved in setting this up, so I can say a little: The people that funded the initial work wanted it permissively licensed. My (somethwat informed) conjecture is that they rank making things secure - even in closed source apps that now could take the code - higher than barring closed forks. It also tracks with the Rust ecosystem in general - APL or derivates are very common in that ecosystem.
What makes you say that? I'm not trying to be argumentative, I'm genuinely interested.
* https://github.com/trifectatechfoundation/sudo-rs?tab=readme...
Well that makes it useless for $WORK (for now), as we use LDAP as our central policy repo (and more generally our user account store). Will have to wait until (at least) that's implemented before we can even consider it.
> It's permissively licensed, unfortunately. Wonder why.
So it can be used distributed with fewer legal hassles.
Well damn that's a shame. I just hate it when people let others use their work in a way they choose, that happens to be less restrictive than my own personal choices.
/s of course.
Copyleft licenses are demonstrably better for open source projects in the long run. We've had enough time to prove that out now.
Look beyond the OS, and much of the tech stack is dominated by non-copyleft open source projects. Both the major web servers--Apache and nginx--are permissively licensed, for example. Your SSL stacks are largely permissively licensed; indeed, most protocol servers seem to me to largely be permissively licensed rather than copyleft.
And I should also point out a clear example where copyleft has hobbled an ecosystem: Clang and LLVM have ignited a major compiler-based ecosystem of ancillary tools for development such as language servers. The gcc response to this is... to basically do nothing, because tight integration of the compiler into other components might allow workarounds that release the precious goodness of gcc to proprietary software, and Stallman has resisted letting emacs join in this revolution because he doesn't want a dependency on non-copyleft software. An extra cruel irony is that Clang appears to be an existential threat to the proprietary EDG compiler toolchain, which would mean it took a permissive license to do what the goal of the copyleft license was in the first place: kill proprietary software.
To the contrary, GNU Hurd is GPL'ed and is much less successful than the linux kernel.
https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt
Instead of using something standard like environment variables, pam has a special "pam_env" that contains facts about the user session that it apparently trusts. Users can override pam_env settings by writing to hidden file in ~.
So, this exploit chain is more accurately described as "yet another example of utilities inventing new, obscure configuration mechanisms for security-critical settings, allowing policy flaws to remain undetected for a long time".
Running security configuration options through a special snowflake IPC mechanism (instead of keeping them in a file where they could actually be inspected by humans) would only make things worse.
I finally understand why they're trying to deprecate `pam_env`, despite its incredible utility. For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.
But it's the same kind of problem as general environment vars - rather than just a name, maybe it needs metadata of where it came from.
To be clear, I'm talking about the unprivileged to allow_active CVE-2025-6018, not the allow_active to root.
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.
(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).
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)
Unfortunately, there's no popular non-Google distro of it.
It also seems to have a lot of new code every year for very few new features. It's as if they get every new intern to rewrite a bit of the innards, and then next summer another intern rewrites it again.
First CoreOS, which forked into Flatcar Linux (now funded by Microsoft) and Fedora CoreOS (rewrite from Gentoo/ChromeOS base to Fedora base), and Google's Container-Optimized System (used heavily in Google Kubernetes Engine).
SecureBlue and Kicksecure are the closest equivalents.
> I wish I had something like GrapheneOS on desktops
Secureblue is essentially as close to GrapheneOS as Desktop Linux can get. Neither my response nor the original question required qubes comparisons. It was merely mentioned.
> grsecurity® is the only drop-in Linux kernel replacement offering high-performance, state-of-the-art exploit prevention against both known and unknown threats.
While secureblue is a full desktop distro (not just a kernel) that integrates key grapheneos hardening tools like their hardened malloc and forks of their hardened chromium and works with flatpak as a base for hardened application deployment.
grsecurity does literally none of that.
You do not understand what you are talking about because if you did you'd be embarrassed for how braindead your response is.
No comments yet
Take filesystems, the official filesystems are UFS(1/2) and ZFS. They have GEOM as LVM and LUKS and more.
That being said, the majority of money and development goes into Linux, which by itself may make it a better system (eventually).
Edit: Of course UFS is not deprecated.
The general lesson from that seems to be that a simpler, well-understood, well-tested and mostly static attack surface is better than a more complex, more fully-featured and more dynamic attack surface. I wonder whether we'll see a trend towards even more boring Linux distributions which focus on consistency over modernity. I wouldn't complain if we did.
While I cannot agree nor disagree on the quality of BSDs (haven't used one in 20 years), I find it funny that in this case a design by committee is proof of quality.
I guess it's better than design by headless chicken which is how the Linux user-space is developed. Personally, I am a big fan of design by dictatorship, where one guy at the top either has a vision or can reject silly features and ideas with strong-enough words (Torvalds, Jobs, etc.) - this is the only way to create a cohesive experience, and honestly if it works for the kernel, there's no reason it shouldn't work in userspace.
I don't think "design" is correct word: organized, managed, or ran perhaps.
> The FreeBSD Project is run by FreeBSD committers, or developers who have direct commit access to the master Git repository.[1] The FreeBSD Core Team exists to provide direction and is responsible for setting goals for the FreeBSD Project and to provide mediation in the event of disputes, and also takes the final decision in case of disagreement between individuals and teams involved in the project.[2]
* https://en.wikipedia.org/wiki/FreeBSD_Core_Team
There is no BDFL, à la Linux or formerly Python: it's a 'board of directors'. Decisions are mostly dispute / policy-focused, and less technical for a particular bit of code.
The right comparison is not between a particular BSD and Linux, its between a particular BSD and a Linux distro.
The full range of distros are very different from each other. Consider Void, Alpine, Gentoo, Chimera, NixOS.....
Different C libraries, init systems, different default command line utilities....
Try running a FreeBSD binary under OpenBSD.
Not to mention illumos-based systems too.
Since then even more stuff went to the Web, but I really I doubt Illumos got any extra traction.
Now if FreeBSD (or indeed illumos) would get CUDA-support we could stop using linux for GPU nodes too.
Could you not run Linux CUDA binaries under FreeBSD's Linuxulator?
They are still missing something like capability based security like iOS and Android have where apps have to be granted access to use things like files or the camera. It may have been considered secure a couple decades ago, but they have fallen behind the competiton.
I wouldn't consider any of these systems "secure", though, as a practical matter. In terms of preventing a breakout, I'd trust an application on OpenBSD with strict pledge and unveil limits, or a Linux process in a classic seccomp sandbox (i.e. only read, write, and exit syscalls), more than any of those other systems. Maybe Capsicum, too, but I'm not familiar enough with the implementation to know how well it limits kernel code surface area. But any application that can poke at (directly or indirectly) complicated hardware, like the GPU, is highly problematic unless there are proofs of correctness for any series of inputs that can be sent by the process (which I don't think is the case).
...like Capsicum?
https://wiki.freebsd.org/Capsicum
The last place in security is iOS.
So while Windows was letting everyone be root?
The answer heavily depends on your configuration. Unprivileged with a spartan syscall filter and a security profile is very different than privileged with the GPU bindmounted in (the latter amounts to a chroot and a separate user account).
And yes, this will most likely be a mess.
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.
You just defined 'life' in general.
What the parent poster meant is that you first need a way to run arbitrary code before local privilege escalation matters, so the exploit chain has to include _something_ that gets you local code execution.
I tend to agree with the parent poster, for most modern single-user linux devices, local privilege escalation means almost nothing.
Like, I'm the only user on my laptop. If you get arbitrary code execution as my user, you can log my keystrokes, steal my passwords and browser sessions, steal my bitcoin wallet, and persist reasonably well.... and once you've stolen my password via say keylogging me typing `sudo`, you now have root too.
If you have a local privilege escalation too, you still get my passwords, bitcoin wallet, etc, and also uh... you can persist yourself better by injecting malware into sshd or something or modifying my package manager? idk, seems like it's about the same.
I haven't actually looked at the numbers, but I strongly suspect that it's true that the overwhelming majority of single-user Linux devices out there are Android devices. If that's true, then it's my understanding that Android does bother to fairly properly sandbox programs from each other... so an escalation to root would actually be a significant gain in access.
https://bugs.gentoo.org/buglist.cgi?quicksearch=udisks
https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt
- SUSE Linux Enterprise 15 (Current LTS)
- Debian 12 (Current LTS)
- Ubuntu 24.04 (Current LTS)
... Were you thinking about a different bug...?
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)
PAM supports a shadow password file as its default configuration. Did you mean something else?