New Linux udisks flaw lets attackers get root on major Linux distros

Scope and impact of the udisks flaw

• Discussion centers on a local privilege escalation requiring:
  • A vulnerable udisks version.
  • A specific PAM configuration (not default everywhere).
• Exploit was demonstrated on Ubuntu, Debian, Fedora, and openSUSE/SUSE; some distros (e.g., Debian, Gentoo with default config, rolling Arch) are already patched or less exposed.
• Several comments note: this is typical of a mature ecosystem where attackers are pushed into narrower, more complex chains.

How serious is local privilege escalation?

• One camp: local root on a single-user desktop doesn’t change much—once an attacker runs code as your user, they can already exfiltrate secrets and persist.
• Counterpoints:
  • On systems with real isolation (Android, multi-user servers, shared environments, academic shell servers), LPE is a big deal.
  • LPEs “turn any basic access into root” and are valuable for chaining with remote bugs, lateral movement, and cloud takeovers.

Linux vs BSD/other OSes

• Some argue Linux desktop feels like an “eternal experiment” in features and security; others say competing OSes are at least as experimental or worse.
• BSDs and illumos are praised for:
  • Smaller, more coherent design (fewer competing subsystems).
  • Capability mechanisms (Capsicum), jails, zones.
• Critics note they still lack user-visible, app-granted capability models like iOS/Android, and suffer from weak vendor/software support.

Secure desktops and hardened distros

• Desire for a “GrapheneOS for desktop” leads to mentions of:
  • Qubes OS (strong isolation but heavy, UX and hardware-acceleration issues).
  • SecureBlue, Kicksecure (hardened Linux distros).
  • grsecurity (commercial, kernel-hardening; debated ethics and value vs “snake oil” accusations).
• Debate over whether kernel hardening alone suffices vs needing userland/app isolation.

Setuid, udisks size, and alternatives

• Recurrent theme: setuid binaries are a recurring LPE source; better to avoid or minimize SUID and reduce trusted code bases.
• udisks is criticized for large LoC and complexity compared to simpler tools (e.g., pmount).
• sudo’s size and CVE history are discussed; suggestions:
  • Use simpler doas / OpenDoas.
  • systemd’s run0 as a non-setuid alternative.
  • Rust rewrite of sudo (sudo-rs) to reduce memory-unsafe bugs, though concerns about rewrite regressions remain.

Containers, namespaces, and kernel CVEs

• Strong disagreement over whether containers are valid security boundaries:
  • Skeptical view: shared kernel = assume escape; kernel CVE count is huge.
  • Pragmatic view: containers work “well enough” in practice; Android uses shared-kernel isolation heavily (plus SELinux).
• Namespaces and user-namespaces have been major LPE sources; some distros now restrict unprivileged access, breaking tools.
• Micro-VM approaches (e.g., kata-style) are mentioned as a stronger isolation layer but with performance and maturity caveats.
• Caveat on CVE counts: Linux kernel intentionally over-assigns CVEs for anything possibly exploitable, so raw numbers overstate practical risk.

PAM, polkit, and configuration pitfalls

• The exploit chain hinges on:
  • PAM’s pam_env / user_readenv behavior and distro-specific PAM configs.
  • polkit “allow_active” rules (privileges granted to the currently active logged-in user, e.g., for mounting devices).
• Key lesson emphasized: obscure, custom auth/config mechanisms (rather than plain, inspectable config) can hide policy bugs for years.

System complexity and “creeping” infrastructure

• Some lament the growth from simple 20-years-ago Unix desktops to today’s maze of daemons, buses, policy engines (systemd, PAM, polkit, udisks, etc.).
• View that enterprise-driven components and tight coupling expand the attack surface and fragility, versus older, simpler setups.
• Others counter that evolving requirements and software never being “done” make such growth inevitable.