[HN Gopher] New Linux udisks flaw lets attackers get root on maj...
___________________________________________________________________
New Linux udisks flaw lets attackers get root on major Linux
distros
Author : smig0
Score : 327 points
Date : 2025-06-20 09:05 UTC (3 days ago)
(HTM) web link (www.bleepingcomputer.com)
(TXT) w3m dump (www.bleepingcomputer.com)
| hbogert wrote:
| 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.
| stavros wrote:
| If you think Linux is an experiment, you should see the other
| OSes.
| khurs wrote:
| Including Openbsd?
| ahofmann wrote:
| I'm pretty sure, that the BSD family is pretty mature and
| secure. Linux is just good enough for most people.
| charcircuit wrote:
| >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.
| NexRebular wrote:
| > They are still missing something like capability based
| security
|
| ...like Capsicum?
|
| https://wiki.freebsd.org/Capsicum
| charcircuit wrote:
| 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 wrote:
| So the capability-based security framework is not missing
| unlike your original statement?
| charcircuit wrote:
| My original statement is about how users have to
| explicitly give programs access to the files and the
| webcam before they can use them. This is missing.
| 8fingerlouie wrote:
| You can use Jails and limit access to hardware resources
| for each jail. Still not as dynamic, but will get the job
| done.
| charcircuit wrote:
| Sure, but this is not done automatically for the user.
| bee_rider wrote:
| For the types of computers BSD is typically run on, just
| unplug the webcam.
| wahern wrote:
| 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).
| resource_waste wrote:
| 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.
| o11c wrote:
| IMO, the real problem with trying to enforce capability-
| based systems on desktop/server environments is the
| correct API isn't implemented. `capabilities(7)` is only
| a tiny subset of `credentials(7)`, `PR_SET_NO_NEW_PRIVS`
| is an abomination, `SCM_RIGHTS` has warts, and
| `close_range` is fundamentally braindead.
|
| We need at least the following sets: effective,
| permitted, bounding (per escalation method?), and the
| ability to make a copy of all of the preceding to
| automatically apply to a child (or to ourselves if we
| request an atomic change). Linux's `inheritable` set is
| just confusing, and confusion means people will use it
| wrong. At least we aren't Windows.
| 8fingerlouie wrote:
| 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.
| assimpleaspossi wrote:
| UFS is not deprecated on FreeBSD.
| hxorr wrote:
| I believe it is the default on netBSD
| graemep wrote:
| > 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 wrote:
| I feel the BSDs are much more different from each other
| than the average Linux distros are.
| graemep wrote:
| 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 wrote:
| That's nothing. Alpine can run Glibc binaries with compat
| libraries.
|
| Try running a FreeBSD binary under OpenBSD.
| graemep wrote:
| But only with compat libraries. Similarly FreeBSD can
| provide Linux compatility. Wine lets you run Windows
| binaries on multiple OSes.
| anthk wrote:
| You can't run neither FreeBSD nor NetBSD binaries under
| OpenBSD.
| gnfargbl wrote:
| 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.
| 8fingerlouie wrote:
| The main strength of WireGuard is that it's simple. It's
| like 10% of the code size of IPSEC.
|
| Less code means less possibility for bugs, and is easier
| to audit.
|
| In my book, WireGuard perfectly follows the UNIX
| philosophy of making a simple tool that does exactly one
| thing and does it well.
| uncircle wrote:
| > 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 wrote:
| > _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]_
|
| * https://en.wikipedia.org/wiki/FreeBSD_Core_Team
|
| There is no BDFL, a 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.
| 8fingerlouie wrote:
| They fill the same position as a BDFL though.
|
| They decide what gets included in the default
| distribution, they set the goals and provider
| sponsorships for achieving them.
|
| So yes, board of directors is probably more fitting.
|
| And then of course you have the people with a commit bit.
| They can essentially work on whatever they like, but
| inclusion into the main branch is still up to the core
| team.
|
| There was a huge debate some years ago when Netgate
| sponsored development/porting of WireGuard to FreeBSD,
| and the code was of a poor quality, and was ultimately
| removed from FreeBSD 13.
| eikenberry wrote:
| Similar to Debian's governing structure.
| NexRebular wrote:
| > I'm pretty sure, that the BSD family is pretty mature and
| secure.
|
| Not to mention illumos-based systems too.
| johannes1234321 wrote:
| 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.
| bee_rider wrote:
| BSD doesn't count, everybody agrees it is the best OS they
| aren't using.
| pandemic_region wrote:
| > I have to say it remains an eternal experiment
|
| You just defined 'life' in general.
| subscribed wrote:
| 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)
| throawayonthe wrote:
| 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 wrote:
| I have been meaning to try out secureblue and hopefully
| even run it on production VMs in proxmox. Is it stable yet?
| IlikeKitties wrote:
| > I wish I had something like GrapheneOS on desktops (yes I
| know about Qubes)
|
| SecureBlue and Kicksecure are the closest equivalents.
| 3abiton wrote:
| What's their selling point compared ro Qubes?
| IlikeKitties wrote:
| https://secureblue.dev/ https://www.kicksecure.com/
| fsflover wrote:
| Qubes isn't mentioned on these pages.
| arbll wrote:
| 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 wrote:
| > 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.
| mathverse wrote:
| No the closest alternative is https://grsecurity.net/
| IlikeKitties wrote:
| Factually wrong from that very site
|
| > grsecurity(r) 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 wrote:
| Yes grsecurity offers actual hardening instead of touting
| snakeoil.
| IlikeKitties wrote:
| 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.
| udev4096 wrote:
| Qubes is definitely hard to daily drive. With it's ancient
| default XFCE design, it looks really ugly. Plus no hardware
| acceleration
| fsflover wrote:
| What's hard about it exactly? It's my daily driver. You can
| install KDE, too: https://forum.qubes-os.org/t/kde-
| changing-the-way-you-use-qu...
| lima wrote:
| 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 wrote:
| 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 wrote:
| 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).
| mathverse wrote:
| 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 wrote:
| Who are they?
| BenjiWiebe wrote:
| Looks like grsecurity has a different view of ethics than I
| do.
|
| Just searching grsecurity on HN turns up some interesting
| stuff.
| sneak wrote:
| 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 wrote:
| An exploit chain, like combining it with the PAM issue they
| mentioned in the very same article, affecting Fedora.
| TheDong wrote:
| 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.
| simoncion wrote:
| > ...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 wrote:
| Does Android use Udisks? I assumed it did not, due to the
| difference in architecture over most traditional
| GNU/Linux desktop systems
| simoncion wrote:
| 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.
| akdev1l wrote:
| Android is not a single user system. Every app, every
| service basically everything gets its own user.
|
| Applications have different user IDs and different
| SELinux contexts.
|
| Android security is tight
| worthless-trash wrote:
| Some services dont run as the same user logging into the
| laptop.
| worthless-trash wrote:
| 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.
| arbll wrote:
| 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
| prmoustache wrote:
| Usually they don't need to be root to access and exfiltrate
| data anyway.
| cozzyd wrote:
| There are plenty of shell servers in academic environments...
| devnullbrain wrote:
| >20 years ago
|
| So while Windows was letting everyone be root?
| amelius wrote:
| What especially feels like an experiment is container
| technology.
| coderatlarge wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| franga2000 wrote:
| 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.
| Geezus_42 wrote:
| Adding ADs to every possible surface, finding new ways to
| obfuscate built-in spyware
| layer8 wrote:
| Active Directories?
| cjg wrote:
| Adverts.
| bee_rider wrote:
| 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.
| yusina wrote:
| Software is rarely "done", so is quite naturally always an
| evolving experiment of sorts.
| jpnc wrote:
| That goes for all (active) software really. Otherwise people
| call it obsolete or abandoned.
| 0points wrote:
| 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.
| resource_waste wrote:
| 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 wrote:
| 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.
| teddyh wrote:
| Fixed two weeks ago (in Debian at least).
| simoncion wrote:
| Yup. And it was never a problem in Gentoo.
| aesh2Xa1 wrote:
| It's there in Gentoo, too.
|
| https://bugs.gentoo.org/buglist.cgi?quicksearch=udisks
| simoncion wrote:
| The other required component of the exploit isn't present
| without operator intervention, so (as I said) it's not a
| problem in Gentoo:
| <https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-6018#c1>.
| udev4096 wrote:
| It's pretty old and only affects openSUSE, the title is extremely
| misleading
| aspenmayer wrote:
| > 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.
|
| https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt
| shakna wrote:
| - openSUSE Leap 15 (Current LTS)
|
| - SUSE Linux Enterprise 15 (Current LTS)
|
| - Debian 12 (Current LTS)
|
| - Ubuntu 24.04 (Current LTS)
|
| ... Were you thinking about a _different_ bug...?
| ethan_smith wrote:
| The vulnerability affects multiple major distributions
| including Ubuntu, Fedora, and Debian (though some have already
| patched it), not just openSUSE as claimed.
| charcircuit wrote:
| Another case of suid causing LPE. When will distros learn that
| suid needs to be removed or disabled if they want security?
| pona-a wrote:
| 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.
|
| As a back-of-envelope estimate, udisks: 0.2875
| CVE7/kLoC * 265.334 kLoC = ~76.28 critical CVEs; pmount:
| 0.2875 CVE7/kLoC * 19.9780 kLoC = ~5.7 CVEs.
| bapak wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rcxdude wrote:
| 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)
| pona-a wrote:
| 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 wrote:
| OpenDoas is used by default by Alpine linux for example.
| pona-a wrote:
| I remember last time I installed it, there was neither
| sudo nor doas preinstalled.
| puzzlingcaptcha wrote:
| sudo was officially depreciated in 3.15 and moved to
| community in the next release
| https://gitlab.alpinelinux.org/alpine/tsc/-/issues/1
| commandersaki wrote:
| 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.
| bbarnett wrote:
| 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.
|
| https://www.youtube.com/watch?v=8XHlowCiLaM
| listeria wrote:
| have you heard of script/scriptreplay?
| script --log-timing file.tm --log-out script.out #
| do something in a terminal session ...
| scriptreplay --log-timing file.tm --log-out script.out
| # replay it, possibly pausing and increasing/decreasing
| playback speed
| lukaslalinsky wrote:
| 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.
| ikekkdcjkfke wrote:
| Why does anything at all need to be executed without
| restrictions though
| salawat wrote:
| 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.
| einpoklum wrote:
| 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.
| Asooka wrote:
| 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 wrote:
| > if any binary has setuid set, it runs as root
|
| More precisely, it runs as the file owner. Which is often
| root.
| kayodelycaon wrote:
| For anyone thinking this is unnecessarily pedantic, it's
| not.
|
| I didn't exactly know what setuid did. I learned
| something today. :)
| vbezhenar wrote:
| You might also research what setgid bit on directories
| do, it's useful sometimes.
| jowea wrote:
| There's been some work on alternatives to setuid sudo. For
| example run0 from systemd.
| j-krieger wrote:
| I can't for the life of me find a list of 210 sudo CVE's. Are
| you sure this is correct?
| pona-a wrote:
| 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.
|
| [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
| mrspuratic wrote:
| You can search by CPE here:
| https://nvd.nist.gov/products/cpe/search and search for
| e.g.:
| cpe:2.3:a:sudo_project:sudo:*:*:*:*:*:*:*:*
| cpe:2.3:a:todd_miller:sudo:*:*:*:*:*:*:*:*
|
| The above pair are the same "sudo", but split arbitrarily,
| perhaps varying by assigning authority preference. (There
| are some other "sudo" named projects too).
|
| Those CPE IDs were determined by a brute-force-ish XML
| grep: xml select -N
| cpe-23="http://scap.nist.gov/schema/cpe-extension/2.3" -t
| --match '//cpe-23:cpe23-item' --if
| 'contains(@name,":sudo:")' -v "@name" -n official-cpe-
| dictionary_v2.3.xml
|
| Now, mapping CVE<->CPE is a tricker problem, it's not 1:1
| (a single CVE can affect multiple product versions), and
| harder here since sudo (1986-ish) predates CVEs (1999) by a
| decade, and CPE (2009) by two. The most capable searches
| seem to be via non-free APIs or "vulnerability management
| $olutions", plus a few CLIs tools that need a lot of care
| and feeding.
|
| This web service is free: https://cve.circl.lu/ But, you
| cannot search directly by CPE right now; you can start a
| search by vendor, then filter by product:
| todd_miller sudo: 58 vulnerabilities sudo_project
| sudo: 42 vulnerabilities
|
| Except, for reasons I don't understand, there are
| duplicates because they somehow source "unique" but
| overlapping CVEs from multiple databases. The true number
| might be 50 combined, of varying severity/concern, but I
| give up now. I'm going to go mutter into my beard for a
| while.
| tormeh wrote:
| Ubuntu is switching to a Rust implementation of sudo:
| https://www.phoronix.com/news/Ubuntu-25.10-sudo-rs-Default
|
| 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.
| stephenr wrote:
| > 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.
| wesselbindt wrote:
| Given that enshittification is a thing, and embrace extend
| extinguish is a thing, I'm inclined to agree with you
| there, without the /s.
| scheeseman486 wrote:
| 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.
| Xylakant wrote:
| 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.
| jcranmer wrote:
| 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.
| umanwizard wrote:
| That is an extremely cherry-picked example. There are
| plenty of examples of permissively-licensed software that
| is very successful, and no evidence that the license
| choice is why Linux won.
| stephenr wrote:
| I'm not even going to point out the hundreds of counter
| examples to your argument.
|
| You clearly didn't understand my point: I'm not arguing
| about whether GPL is better than MIT or BSD or even
| SSPL/etc.
|
| My point is that if someone else chooses to release their
| software with _less restrictions_ on it than I would
| choose, that 's literally none of my business.
|
| They wrote the fucking thing, they get to choose how it's
| fucking licensed.
|
| Plenty of organisations (and thus people) skip using GPL
| licensed software due to inability or unwillingness to be
| bound by it's terms.
|
| I'm still waiting for the day the GPL camp says they're
| not going to use things like OpenSSH, Apache, Nginx,
| Postgres, Python, Ruby - because they're too fucking
| permissive.
| spookie wrote:
| Good take. Also note the very well thought out decision
| from Linus and team to keep GPLv2, it is a balancing
| game.
|
| In the end, if you want projects to succeed they need
| contributors. Unfortunately, some of them need to be
| reminded to play fair more than others, and in those
| cases the legalese helps.
| Xylakant wrote:
| > It's permissively licensed, unfortunately. Wonder why.
|
| 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.
| throw0101b wrote:
| > _Some functionality is not supported, such as [...] storing
| config in LDAP using sudoers.ldap, and cvtsudoers._
|
| * 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.
| johnisgood wrote:
| 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.
| faceplanted wrote:
| > 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 wrote:
| Whenever a complex system is rewritten, there are a lot
| of bugs and regressions in it.
| djmips wrote:
| All the rewriters are offended by the truth.
| johnisgood wrote:
| Yup, hence why the downvotes. :( I thought it was a no-
| brainer, but I guess not.
| vlovich123 wrote:
| I'm a pretty big advocate on Rust and while Rust does
| protect classes of certain kinds of bugs and probably
| encourages better unit test hygiene and thus higher code
| quality, it does not protect against logic bugs and all
| the historical CVEs and thus it's possible for previous
| exploits vectors to resurface. Thus it's not an
| unreasonable prior to assume there are vulnerabilities
| lurking.
|
| On the other hand, if the replacement isn't targeting
| full sudo feature set and also reducing the amount of
| code and/or making architectural improvements like
| keeping most code not running as root, then the blast
| area of such logic bugs can be reduced.
| Vilian wrote:
| Read the sudo license that argument don't make sense when
| sudo license is even more permissive
| tgbugs wrote:
| 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.
| icar wrote:
| Was Arch ever affected?
| BirAdam wrote:
| 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.
| jillesvangurp wrote:
| Briefly maybe, until somebody fixed it and then everyone
| updated and moved on with their lives. That kind of is the
| point of rolling distributions.
| PhilipRoman wrote:
| 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).
| pinoy420 wrote:
| Given this. Why is every linux device not rooted then.
| hnlmorg wrote:
| Because GP is talking about theoretical vectors of attack in
| highly secure environments. Whereas you are now discussing
| why hackers don't target devices with zero-financial gain.
|
| Also just because syscall A might be vulnerable to a
| particular type of attack, it doesn't mean that service B
| uses that syscall, let alone calls it in a way that can be
| exploited.
| duxup wrote:
| I think in the land of people with ill intent to exploit such
| things they have more potential targets and security
| vulnerabilities than they can spend time exploiting. A given
| vulnerability may be terrible, but it might not coincide with
| something worth bothering with for a given person with ill
| intent. There's a factor of human choice / payoff at play.
| tptacek wrote:
| I think a majority of systems security people, if asked,
| would say they assume an attacker with code execution on a
| Linux system can raise privileges.
| uncircle wrote:
| https://xkcd.com/1200/
| mindcrime wrote:
| I use my laptop logged in as root, so that's not an issue!
| Dylan16807 wrote:
| Not really relevant, the threat being discussed is for multi-
| user systems.
| rob_c wrote:
| And your pulse audio service is running as which user now?
| This is a local exploit but for any system supporting the
| mentioned combination of services, aka a lot of them,
| including the RHEL derivatives and likely Ubuntu.
|
| https://almalinux.org/blog/2025-06-18-test-patches-for-
| cve-2...
| Dylan16807 wrote:
| > And your pulse audio service is running as which user
| now?
|
| I'm not sure, I appear to be running pipewire. But
| assuming it's not my own account: not a user that will
| initiate an attack. A user account that allows logins or
| runs external servers would have to get compromised
| first, and at that point it can use the exploit directly
| with no need to touch pulseaudio.
|
| If there's only one directory in your /home, it's very
| unlikely the urge for admins to patch this is directed at
| you.
| shakna wrote:
| Pipewire runs under the pipewire user, managed by systemd
| or OpenRC. Which means any of their managed processes can
| start a new pipewire user process.
|
| A local priv-sec is one exploit [0] away from a remote
| one.
|
| [0]
| https://www.bleepingcomputer.com/news/security/hackers-
| explo...
| eddd-ddde wrote:
| The best is they absolutely can install drivers without your
| permission unless your system is encrypted. So it's even
| worse!
| quotemstr wrote:
| 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 wrote:
| Wouldn't Android's kernel have most of the hardening steps /
| disabled features described in GP's comment?
| quotemstr wrote:
| No. Things like eBPF, strace, and packet filtering are
| enabled. Android uses SELinux and other facilities to limit
| the amount of code the kernel will allow to access these
| features. Big difference from their being compiled out of
| the kernel entirely as the OP suggests is necessary.
| galangalalgol wrote:
| Container isolation can fail at shared libraries in
| shared layers too can't it? My evil service is based on
| the same cooltechframework base layer as your safety
| critical hardware control service and if there is a
| mistake in the framework...
| immibis wrote:
| then it affects each one separately since they are
| separate processes. The fact they run the same code is
| irrelevant if the data is separate.
| galangalalgol wrote:
| Separate processes running the same shared instructions.
| If you compromise and modify those shared instructions,
| the othe container runs instructions of your choosing.
| kbolino wrote:
| Layers are COW so one container modifying a layer has no
| effect on other containers started from the same image.
| Of course, preexisting vulnerabilities will remain but
| they'd have to be separately exploited in each container.
| egberts1 wrote:
| Worse, cannot disable eBPF due to too many packages
| demanding it.
|
| Namely, nft tables and its filtering.
| antoinealb wrote:
| Android delegated some security features to a different
| kernel called Trusty that is separated from the main Linux
| kernel using virtualisation. That kernel runs high value
| security services.
|
| https://source.android.com/docs/security/features/trusty
| quotemstr wrote:
| Yes, but that's not the main load-bearing security part of
| the system. Trusty doesn't isolate apps from each other. It
| doesn't isolate work profiles from user profiles. Regular
| SELinux-augmented thoughtfully-used uid- and process-
| isolation does that.
| zamalek wrote:
| If you weren't aware, containers aren't a security boundary.
| Things like bubblewrap are.
| rlpb wrote:
| Semantics make hard assertions about "containers"
| worthless. It depends on what one means by a container
| exactly, since Linux has no such concept and our ecosystem
| doesn't have a strict definition.
| NewJazz wrote:
| What to you think bubblewrap is, if not a container
| runtime?
| eyberg wrote:
| bubblewrap is actually worse - there are known escapes in
| there that haven't been fixed for years
| stefan_ wrote:
| Ironically Ubuntu 24 now blocks users from accessing
| namespaces because that kernel interface had a bunch of local
| privilege escalations, breaking programs that want to use
| them for isolation.
| holowoodman wrote:
| For the last 10 years or so, namespaces in Linux were the
| source of the absolute hightest number of local privilege
| escalations and sometimes even arbitrary code executions in
| kernel space. Building a kernel without user namespace
| support has been goto-advice for multiuser systems for
| almost as long. Ubuntu is just late to the game because
| they mostly have server or single-user-desktop customers.
| ranger_danger wrote:
| Seems ironic considering namespaces are highly utilized
| for isolation/security purposes.
| immibis wrote:
| I presume they're left enabled for root.
| stefan_ wrote:
| The same software that wants to use namespaces for
| isolation will refuse to run as root.
| NexRebular wrote:
| I've even seen namespaces used for hiding malicious
| software in Ubuntu systems too.
| stefan_ wrote:
| Actually I think device drivers got you beat there, but
| no ones suggesting we break them for users safety. Ubuntu
| today is more user hostile than Windows.
| crest wrote:
| That's a cheap cop out.
| rob_c wrote:
| You've worked in security theatre before then ;)
| NicolaiS wrote:
| 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
| rcxdude wrote:
| Indeed. They issue a CVE for every bugfix, because it's long
| been the position of the linux maintainers that there's no
| meaningful distinction between a security bug and a regular
| bug.
| karlgkk wrote:
| > memory errors with no viable exploit path
|
| i dont appreciate putting "vulns" in scare quotes, if that
| was your intent
|
| swiss cheese theory. all it takes is someone changing a
| component that allows that vulnerability to be chained into
| an exploit, which has happened many times.
|
| these should be tracked, and in fact, it's very helpful to
| assign cves to them
|
| but yeah, raw numbers is less useful. in fact, cves as a "is
| it secure or not" metric are pretty rough. it makes it easier
| to convince vendors to keep their software up to date,
| though...
| stouset wrote:
| > anyone still thinks that they can draw a security boundary
| anywhere with a shared kernel
|
| Containers are everywhere.
| tptacek wrote:
| They don't work as reliable security boundaries; they're
| developer/ops tools.
| SEJeff wrote:
| Thomas, what are your thoughts on micro-vms such as kata
| containers? You can use them as a backend for docker in
| place of runc.
|
| I'm sure you're well aware, but for the readers, they are
| isolated with a CPU's VT instructions which are built to
| isolate VMS. I still think "containers don't contain" in a
| very Dan Walsh boston accent, but this seems like a
| respectable start.
|
| https://katacontainers.io
| tptacek wrote:
| I have no strong opinion other than that untrusting
| cotenants shouldn't directly share a kernel.
| burnt-resistor wrote:
| They're slow and so unsuitable for dev work. They might
| be somewhat better for prod, but it depends on a wide
| selection of unproven hypervisors.
| tptacek wrote:
| Which "unproven" hypervisors are those? Kata works with
| Firecracker.
| hinkley wrote:
| 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.
| DCKing wrote:
| > they should really look at kernel CVE database
|
| 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
| andrewmcwatters wrote:
| This is a common complaint with the whole CVE process to
| begin with, and isn't even a Linux thing.
| PhilipRoman wrote:
| You're right. I review each one carefully, so here I mean
| only the real ones. It's still a massive amount of
| vulnerabilities, even after excluding obscure drivers or
| features that aren't used on headless systems.
| belorn wrote:
| Could someone describe what 'allow_active' privileges is on
| Linux?
| rcxdude wrote:
| 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.
| yrro wrote:
| https://www.freedesktop.org/software/polkit/docs/latest/polk...
| mkj wrote:
| 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.
| hansmayer wrote:
| IPC ?
| hedora wrote:
| The GP doesn't understand the vulnerability:
|
| 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.
| mkj wrote:
| 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.
| Piraty wrote:
| https://xeiaso.net/talks/surreal-horror-pam-2021-11-09/
| o11c wrote:
| 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.
| yrro wrote:
| > 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.
|
| The only safe way to use pam_env's `user_readenv` parameter
| is as the final rule of `type=session`. This behaves as
| you'd expect, affecting the child process only.
|
| It appears that openSUSE enables the option for other rule
| types (auth and/or account), in which case it affects the
| parent process as well. Oops!
|
| For the record, user_readenv has been disabled since:
| commit 4c430f6f8391555bb1b7b78991afb20d35228efc
| Author: Tomas Mraz <tm@t8m.info> Date: Mon Oct 11
| 14:24:30 2010 +0000 Relevant BUGIDs:
| Purpose of commit: bugfix Commit
| summary: --------------- 2010-10-11
| Tomas Mraz <t8m@centrum.cz>
| * modules/pam_env/pam_env.c: Change default for
| user_readenv to 0. *
| modules/pam_env/pam_env.8.xml: Document the new default for
| user_readenv.
|
| ... PAM 1.1.3. And it's been deprecated for a while, to be
| removed in a future release entirely.
| rob_c wrote:
| NO, this is NOT environment variables.
|
| 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.
| Dylan16807 wrote:
| Relax, someone else already explained it without shouting.
| rob_c wrote:
| At the time they hadn't and I'm fed up of the jumping to
| conclusions that env vars are the cause of any security
| issue. This is blaming poor code from poor devs on expert
| features from UNIX all to often.
|
| Worrying when said person has authored a widely used
| security product(!). This is a bad trend in the industry
| that needs to stop.
| Dylan16807 wrote:
| > At the time they hadn't
|
| Their comment was before yours.
| rob_c wrote:
| if that's the comment you mean, it also misses the point
| 1970-01-01 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| 0xbadcafebee wrote:
| 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)
| capitainenemo wrote:
| devuan also uses a stub fake libsystemd but it really is just a
| stub to avoid broken calls.
| Sunspark wrote:
| Make BSD great again!
| 0xbadcafebee wrote:
| Well, damn... that's not a bad idea. It's only been 20 years
| since I last tried FreeBSD. Anything changed?
| tux1968 wrote:
| > 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?
| aidenn0 wrote:
| They mean that they can't use shadow passwords _wihout_ PAM
| (i.e. the way most unix systems worked circa 1990).
| blueflow wrote:
| 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.
| b0a04gl wrote:
| 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 wrote:
| Golden opportunity for bitcoin miners on AWS.
| fitsumbelay wrote:
| Hello, I need some help understanding how the combined exploits
| affect users of not-SUSE distros. Thanks
| baobun wrote:
| 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.
| Arnavion wrote:
| 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`
___________________________________________________________________
(page generated 2025-06-23 23:00 UTC)