Memory-safe sudo to become the default in Ubuntu

Original Article ↗ Hacker News Discussion ↗

Security issues in classic sudo

  • Several commenters note real-world memory bugs and vulnerabilities in sudo (e.g., CVE‑2021‑3156, “unescape overflow”), plus a history of advisories, so memory safety isn’t a hypothetical concern.
  • Others add that sudo has had non‑memory security issues as well, and some have seen it crash due to memory errors.
  • A counterpoint is that logic flaws remain possible even in a memory‑safe implementation; Rust only removes certain classes of bugs.

sudo-rs design: features, LDAP, and compatibility

  • sudo-rs explicitly drops some “niche” features (notably direct LDAP integration) to reduce complexity and attack surface.
  • That alarms people who rely on LDAP‑based centralized sudoers; clarifications say sudo-rs can still work with LDAP via NSS/SSSD and PAM rather than sudo’s own LDAP code.
  • There’s debate over whether a “sudo-lite” in C (feature‑reduced but not rewritten) would have been enough.
  • sudo-rs is not a full drop‑in: some flags (e.g., -E) aren’t supported, and maintainers say they don’t plan to add rarely used features.
  • Some argue a safer tool should have a different name (like doas) so users don’t assume 100% sudo compatibility.

Alternatives: doas, run0, capabilities, and elevation models

  • OpenBSD’s doas is praised as a tiny, simple alternative, but Linux ports are criticized as poorly maintained and with unfixed security issues.
  • run0 (systemd‑based, daemon model, no setuid) is discussed as an architecturally safer pattern, but it requires systemd and is still C, so memory bugs remain possible.
  • There’s a long subthread on whether setuid binaries are the main problem vs. any elevation mechanism; many argue any “become privileged” path can be abused via social engineering.
  • Some advocate capability-based or Android/ChromeOS‑style models where users rarely/never escalate; others point out that this conflicts with traditional GNU/Linux expectations and workflows.

Rust, rewrites, and Ubuntu’s broader direction

  • Supporters see Rust as a clear improvement for security‑critical components, especially when existing C code has a long bug history.
  • Skeptics worry about “rewrite risk”: new logic bugs, loss of hard‑won behavior, and missing edge‑case features; they point to sudo‑rs issue trackers with security/logic problems.
  • The move is framed as part of Ubuntu’s wider “oxidation” (e.g., uutils for coreutils), trading C/GNU components for Rust/MIT‑licensed ones.
  • Some welcome this; others distrust Canonical’s general trajectory (snaps, auto‑updates, custom tools like netplan) and prefer Debian or other distros for servers.