Changing your sudo implementation is about as interesting as changing your underpants, but switching to an entirely new operating system is far more exciting.While people debate the intricacies of sudo and setuid, one vendor leaves the door open to attackers—but it's not what you think.There are only a few ways we can solve the sudo problem: better implementations, safer code, or containment.
Opendoas, run0, and sudo-rs do these to varying degrees, but Qubes does one of them so well that sudo doesn't even matter.The problems with sudo A huge attack surface and setuid Sudo has served the *nix world since the 80s, but it comes with two well-known problems.The sheer project size, for one: it has well over 100k lines of code, and its attack surface is gigantic.
Nothing buries information quite like a deluge of noise, and an ocean of code is the perfect cover.The second issue is the reliance on setuid, a permission bit that makes executables run as their owner.For example, sudo is owned by root, so a user executing it causes the binary to run as root.
The problem with this approach lies with unprivileged users running privileged code.If the binary has any flaws, they can inject an exploit, which then runs with root privileges.This is called arbitrary code execution or privilege escalation.
Related These 7 TUIs Will Bring Your Terminal Experience Up-to-Date GUIs are great but TUIs are terrific! Posts 4 By Bobby Jack Run0 A truly different approach to privileges First on the list of alternatives is run0, a command bundled with systemd since v256.Its primary goal is to sidestep sudo's failings using a fundamentally different model.Instead of using setuid, it opts for privilege elevation via polkit, a policy daemon that grants granular permission controls.
Run0 works differently from sudo.Where sudo foo forks into a privileged "foo," inheriting much of its execution context, run0 doesn't do that.Instead, it executes processes in a forked pseudo-terminal (PTY), isolating it.
Environment variables, cgroup assignments, security context, and file descriptors are all missing from this new context.Run0 feels a little rough around the edges; for example, it doesn't cache credentials.Consequently, sequential commands will reprompt you for authentication, which is a bit of a bummer, but not exactly unsolvable.
Run0 is available with most systems that use systemd, and you can try it yourself right now: run0 ls You can also run an interactive terminal (like su or sudo su): run0 # No command Sudo-rs After writing this paragraph, I considered rewriting it in Rust Run0 isn't the only viable alternative, with sudo-rs being the next obvious candidate.It's a drop-in replacement(-ish) for sudo developed by the Trifecta Tech Foundation and now adopted by Canonical as part of their effort to oxidize Ubuntu.Its value proposition is simple: A sudo-like binary written with memory-safe code.
Memory corruption attacks are the bread and butter of local privilege escalation, and if they can solve that, then there's no need for an entirely different approach.Related These 7 Bash tricks will change how you use the terminal Bash hides a lot of shortcuts in plain sight.Here are seven that'll cut your typing in half.
Posts 3 By Graeme Peacock Opendoas A tiny codebase, with an even smaller commit history The other option is opendoas, a fork of OpenBSD's doas.Both aim to replace sudo, with a focus on simplicity: a smaller codebase means less attack surface."Smaller" is an understatement of their proposition because opendoas has around 3000 lines of code compared to hundreds of thousands in sudo.
If people can read and understand the code, spotting vulnerabilities is much easier.However, opendoas appears to lack regular maintenance, with several years passing since its last commit.I don't know if it's because the codebase is so small and feature-complete that changes are exceedingly rare, but the upstream doas was updated as recently as 2024.
Qubes OS Sudo is essentially useless One of Qubes' most controversial decisions was to disable sudo altogether.The idea is strong isolation is all you need.Qubes VMs don't just protect your system; they protect your data by dividing it into security domains—banking, general browsing, work, etc.
Generally speaking, root-owned directories come from a separate system that an attacker cannot permanently affect because it's reset upon reboots—it also contains only general system data, anyway.The important stuff sits in your home directory (password databases, browser sessions, etc.), and attackers don't need root to steal that.The notion of using sudo on Qubes is therefore redundant, and strong boundaries between domains are enough.
In short, sudo protects one's system from persistent and malicious changes, but VMs on Qubes don't have that problem.Only user data is vulnerable, and that's the case on every system.All three approaches make sense, but Qubes makes sudo entirely redundant Run0 is already available in most systems, so that's a major bonus.
However, the UX needs polishing, and systemd has a poor reputation, which may affect adoption.Rust rewrites seem like a sensible approach because of familiarity.For critical system code, memory-safe languages are a better fit.
However, I don't want to rile any diehard C proponents up or ignite a heated debate about Rust in Linux.For traditional privilege elevation, I can see an amalgamation of all three alternatives being most effective: a small codebase, a memory-safe language, and avoiding setuid.It might seem like a cop-out, but all of them would be at the top of my list.
For most, replacing sudo is a long way off, given its first-mover advantage.They simply don't care enough—they see sudo as an inconvenience rather than a necessity.Whatever the outcome, sudo (on my desktop) sits there without a password.
Perhaps the real replacement isn't one of the aforementioned programs after all, but an entirely novel approach.
Read More
