Sudo and its alternatives

Sudo is a ubiquitous tool for running commands with the privileges of another user on Unix-like operating systems. Over the past decade or so, some alternatives have been developed; the base system of OpenBSD now comes with doas instead, sudo-rs is a subset of sudo reimplemented in Rust, and, somewhat surprisingly, Microsoft also recently announced its own Sudo for Windows. Each of these offers a different approach to the task of providing limited privileges to unprivileged users.

The origins of sudo go back to the beginning of the 1980s and 4.1BSD running at the State University of New York, Buffalo. The full history of the program will not be repeated here, but a nice overview of it is available on the sudo website. That history is sparse on details about the first release of "CU sudo", which is the currently prevailing sudo; it simply says that it was CU sudo version 1.3 that was released in 1994. The exact date appears to have been February 9, 1994 from a post to comp.unix.admin — just a bit over 30 years ago.

Sudo has been through multiple iterations and reimplementations over the years. CU sudo was named after the University of Colorado, where it was created by Todd C. Miller. He still maintains it, although naturally many people have contributed to it over the decades. The "CU" prefix was dropped from the name in 1999.

What does sudo do?

Sudo works by authenticating the user and then executing the program given as a command-line parameter, with the effective user ID of the user indicated in the -u parameter (root by default). Most commonly, a system administrator configures sudo by listing specific users or groups and their allowed capabilities in the /etc/sudoers configuration file. Sudo supports fine-grained control to, for example, allow a user to only run specific commands with the identity of a specific other user, rather than any command as any user. A user could run sudo cat foo to read the file foo that their regular account does not have permission to read, or sudo -i to get an interactive superuser shell.

As an important contrast to the related su utility, users do not have to know the superuser password of the system; instead they authenticate with their own password. Authentication without a password can also be set up. For convenience, sudo keeps "ticket files" for recently authenticated users, so that they do not have to re-input their password for a short time after their last sudo invocation.

OpenBSD and doas

To assume the identity of another user, sudo must invoke some privileged system calls, and therefore its file mode must be setuid root. Those types of programs have extraordinary security requirements and must do their job carefully in order to prevent unintended privilege escalation.

Having identified that sudo is such a program and a complicated one, OpenBSD developers came to the conclusion that it was too risky. Starting with OpenBSD 5.8, released in October 2015, the default user-identity switcher tool has been "doas", or "Dedicated OpenBSD Application Subexecutor". It was developed by Ted Unangst, who had "personal issues" with the configuration of sudo. He wrote a blog post in July 2015 explaining his reasons for the creation of doas. One of those was that sudo was simply too complicated for most people's needs:

The core of the problem was really that some people like to use sudo to build elaborate sysadmin infrastructures with highly refined sets of permissions and checks and balances. Some people (me) like to use sudo to get a root shell without remembering two passwords. And so there was considerable tension trying to ship a default config that would mostly work with the second group, but not be too permissive for the first group.

Another was that it contained too much code for a privileged process:

There were some concerns that sudo was too big, running too much code in a privileged process. And there was also pressure to enable even more options, because the feature set shipped in base wasn’t big enough. (As shipped in OpenBSD, the compiled sudo was already five times larger than just about any other setuid program.)

Prior to the blog post, there was a thread on the openbsd-ports mailing list announcing a decision by Miller, who is also heavily involved with OpenBSD, and Theo de Raadt to move sudo from OpenBSD's base repository to the so-called ports tree. BSD operating systems generally come with the core operating system in a repository called "base", along with a "ports" tree offering third-party software in source-code format. Apart from a separate openbsd-tech thread, there isn't much overt discussion to be found about sudo's problems prior to the removal from base. It appears that one day Unangst just thought it best to make a slimmer replacement; De Raadt and Miller were seemingly on board from the start.

Doas is a bare-minimum sudo-like tool; it has a simplified configuration file syntax and does not have support for authentication schemes other than system-local BSD Authentication — see Wikipedia for an overview or the login.conf man page for details. Taking a look at the short man page for doas.conf gives a good idea of its scope.

A Linux port of doas also exists by the name OpenDoas and is available for many distributions.

Vulnerabilities and "rewrite it in Rust"

As with any software, sudo has had its share of security problems. It is not an egregious stream of vulnerabilities by any means, but something pops up every now and then. Since sudo is written in C, a portion of those bugs involve memory safety. Most recently, in CVE-2023-27320, a double-free bug was patched, albeit one that only affected rare configurations. Another, more severe, vulnerability from last year was CVE-2023-22809, though it is unrelated to memory safety. It concerned a mishandling of environment variables by the sudoedit command, which allowed a local attacker to append extra files to be edited with extra privileges.

Sudo-rs is an effort to write a drop-in replacement for "all common use cases of sudo" in Rust; its GitHub README calls it "a memory safe implementation of sudo and su". The project only targets Linux-based systems with a 5.9 kernel or newer. Development is sponsored by the Prossimo project, which is part of the Internet Security Research Group (ISRG); there is an announcement blog post of the project from April 2023.

The project is also affiliated with Ferrous Systems, a company offering a safety-standards-qualified Rust compiler and consulting, which reported on a security audit of sudo-rs in November 2023. The audit discovered one moderate and two low-risk issues; the moderate one being a path traversal vulnerability that was found to affect Miller's sudo as well.

Similarly to doas, sudo-rs also only targets a subset of sudo's capabilities. From the README:

Some parts of the original sudo are explicitly not in scope. Sudo has a large and rich history and some of the features available in the original sudo implementation are largely unused or only available for legacy platforms. In order to determine which features make it we both consider whether the feature is relevant for modern systems, and whether it will receive at very least decent usage. Finally, of course, a feature should not compromise the safety of the whole program.

Sudo-rs does not seem to get much use currently. At the time of this writing, the Crates.io statistics show a figure of 663 all-time downloads. The most notable deployment of sudo-rs that was found is in Wolfi OS — a minimalist distribution (or "undistro" as the project calls itself) from Chainguard, Inc., focused on solving supply-chain issues in container images.

Cutting down on features

Both doas and sudo-rs achieve a portion of their goals by intentionally omitting features that sudo supports. This is a sensible angle to minimize attack surface and reminiscent of the OpenBSD-originated LibreSSL project. After the major OpenSSL vulnerability dubbed Heartbleed in 2014, OpenBSD forked OpenSSL into LibreSSL and removed substantial amounts of legacy and esoteric functionality in an effort to improve the security of the library.

While the vulnerabilities found in sudo have not been as severe as Heartbleed, it might be prudent to get ahead of such a hypothetical event by switching to a streamlined alternative, especially when some of the more advanced or more complicated features of sudo are not required. Though sudo is not exposed to the network like OpenSSL, many of the same concerns that led to LibreSSL were factors in the development of doas — and in the same time frame.

Doas supports only a core subset of sudo's feature set, so it cannot really be recommended for anyone who has even slightly more complicated authentication needs than local user accounts. There is no support for integration with LDAP or Kerberos, for instance. However, sudo-rs does call out to Pluggable Authentication Modules (PAM) to authenticate the user, so it can support non-local authentication schemes such as LDAP and Kerberos via the usual Linux mechanism for that.

Notably, sudo-rs maintains a list of past sudo CVEs with an estimation of their applicability to sudo-rs. Most of them are listed as not applicable because the affected functionality is not implemented in sudo-rs.

Others

Once an organization starts to get larger, it quickly becomes advisable to maintain privilege and identity information in a centralized system such as LDAP or Active Directory. Some su- or sudo-like tools exist precisely with these use cases in mind. Sudo itself, for instance, has support for LDAP integration.

For the Kerberos network-authentication protocol, there is ksu or "Kerberos su", provided by the MIT package. Sudo's website lists various other sudo alternatives as well. Most of these are outdated or otherwise not noteworthy, and some are system-specific tools for non-Linux systems or commercial products. Some on the list, such as priv, GNU userv and ssu, look like long-abandoned pet projects or academic research from roughly 25 years ago.

As a surprise to many, Microsoft announced "Sudo for Windows" on February 7 as part of a Windows 11 insider-preview build. The blog post claims that Microsoft is "open-sourcing this project" on GitHub, but the only code available on the repository at the time this article was written is a PowerShell wrapper that calls out to sudo.exe. It is unclear where the source for that binary is hosted.

The announcement outlines a few different ways to configure the tool's behavior; it can either launch the privilege-elevated process in a new terminal window or in the existing window. The actual privilege elevation looks to be handled by the User Account Control (UAC) subsystem, complete with the graphical confirmation dialog. Sudo for Windows is not a port or fork of Miller's sudo, nor does it work the same way. The blog post also links to a separate sudo-like tool for Windows called gsudo, which it says has more features.

Identity and access management is certainly a rich and complicated topic, not to mention a delicate one. The tools and frameworks that we rely on daily for security in authentication and authorization are under constant scrutiny. The 30-year-old sudo has had a long run as the most popular tool for what it does, but perhaps the security diehards of OpenBSD, along with the memory-safety-focused Rust developers behind sudo-rs, are onto something. We shall have to wait and see what the future holds for sudo and its alternatives.