Why Ubuntu 26.04 Switches to sudo‑rs: Rewriting 46‑Year‑Old sudo in Rust

1. History of sudo

In the late 1970s Bell Labs developers Bob Coggeshall and Cliff Spencer created sudo (SuperUser DO) to let ordinary users temporarily obtain root privileges for specific commands. Before sudo, Unix offered only two options: log in as root (dangerous) or switch to root with su (requires the root password).

Core functionality includes:

Basic usage examples:

# Execute a single command as root
sudo apt update

# Switch to a root shell
sudo -i

# Run a command as a specific user
sudo -u postgres psql

Permission configuration via /etc/sudoers, e.g. %wheel ALL=(ALL) NOPASSWD: ALL or limiting a user to restart nginx.

Security features: password‑less reuse within 5 minutes, detailed logging, environment variable filtering, resource limits.

Technical debt:

Codebase exceeds 100 000 lines of C, with many legacy macros, conditional compilation, and obsolete features (LDAP, NIS).

Security record: >100 CVEs from 2012‑2021, including the critical Baron Samedit (CVE‑2021‑3156) buffer‑overflow that allowed privilege escalation.

Maintenance challenges: frequent maintainer turnover, low interest from younger developers, high cost and risk for new features.

2. sudo‑rs: Redefining privilege management in Rust

Project background – initiated by the Internet Security Research Group (ISRG) as part of the Prossimo project to rewrite critical infrastructure components in a memory‑safe language.

Timeline:

2023‑08: sudo‑rs v0.2.0 released, first security audit.

2025‑08: v0.2.8 released, second audit.

2025‑10: Ubuntu 25.10 defaults to sudo‑rs.

2026‑04: Ubuntu 26.04 LTS makes sudo‑rs the default sudo implementation.

Supported platforms include Ubuntu 25.10+, Arch Linux, Fedora 42+, Debian 13+, FreeBSD, NixOS.

Why Rust? The language provides:

Ownership‑based automatic memory management – eliminates buffer overflows and leaks.

Option types that force null handling – compile‑time prevention of null‑dereference.

Borrow checker – compile‑time guarantee of thread safety, preventing data races.

Compile‑time errors for undefined behavior – dramatically reduces security hazards.

Core features of sudo‑rs:

Memory safety – classic C overflow example:

// classic overflow
char buffer[64];
strcpy(buffer, user_input); // overflow if input > 64 bytes

Rust prevents this at compile time:

// compile‑time check
let mut buffer = [0u8; 64];
buffer.copy_from_slice(user_input); // length checked

Safer defaults – the following options are enabled by default:

# use_pty      # run commands in a pseudo‑terminal to prevent keylogging
# pwfeedback   # show asterisks while typing password (first time in 46 years!)
# env_reset   # reset environment variables to avoid injection

Code size reduction – classic sudo >100 k lines of C; sudo‑rs ≈30 k lines of Rust (≈70 % reduction).

Advantages

Easier maintenance and audit.

Reduced attack surface.

Faster development of new features.

Modern development practices

Continuous integration with automated tests per pull request.

Regular third‑party security audits.

Active open‑source community with many young contributors.

3. Feature comparison: sudo vs sudo‑rs

3.1 Ordinary‑user perspective

Command syntax is identical. Example on Ubuntu 26.04 where sudo points to sudo‑rs:

# Install a package
sudo apt install nginx   # still works

# Switch to a root shell
sudo -i

Password feedback – classic sudo shows no feedback; sudo‑rs displays asterisks:

# sudo‑rs output
[sudo] password for user: ******
# classic sudo: no visual feedback

Clearer error messages, e.g.:

Sorry, user 'webadmin' is not allowed to execute '/bin/bash' as root on server01.

3.2 Administrator perspective

Supported features (fully compatible):

All common command‑line options (e.g., -u, -i, -E).

Standard sudoers syntax.

PAM authentication.

Syslog logging.

Removed or changed features (with reasons and alternatives): sendmail notification – outdated; use log aggregation tools.

LDAP configuration – complex and error‑prone; manage via configuration‑management tools.

Command‑line wildcard expansion – common source of config errors; specify full command paths. cvtsudoers tool – limited usefulness; edit configs manually.

Configuration differences – sudo‑rs enforces stricter defaults (UTF‑8 sudoers, mandatory PAM, resource limits via /etc/security/limits.conf).

# Example sudo‑rs configuration file
webadmin ALL=(ALL) /usr/sbin/nginx, /bin/systemctl restart nginx

3.3 Security comparison

Memory‑safety vulnerabilities: classic sudo has >100 CVEs historically; sudo‑rs has 0 after two independent audits.

Code complexity: classic sudo >100 k lines; sudo‑rs ~30 k lines – ≈70 % attack‑surface reduction.

Default secure configuration: classic sudo requires manual enablement; sudo‑rs enables secure defaults out of the box, lowering misconfiguration risk.

Audit frequency: classic sudo irregular; sudo‑rs undergoes regular third‑party audits, providing continuous security assurance.

4. Why rewrite: technical decision logic

"This is not about using a new language for its own sake. Our goal is to solve real problems: reduce memory‑safety bugs, simplify maintenance, and improve security. Rust is simply the tool to achieve that," – Marc Schoolderman, chief engineer, Ubuntu Summit 25.10.

Refactor vs rewrite:

Refactor existing C code

❌ Massive effort – estimated 10 person‑years.

❌ High risk – changes to legacy code could introduce new bugs.

❌ Limited impact – cannot eradicate memory‑safety issues.

Rewrite in Rust

✅ Moderate effort – core functionality completed in ~3 years.

✅ Controllable risk – Rust compiler enforces safety guarantees.

✅ Significant impact – eliminates memory‑safety vulnerabilities at the source.

Gradual migration strategy:

Stage 1 (Ubuntu 24.04‑25.04) – sudo‑rs available in the universe repository; classic sudo remains default.

Stage 2 (Ubuntu 25.10) – sudo command points to sudo‑rs; classic sudo renamed to sudo‑ws (still switchable).

Stage 3 (Ubuntu 26.04 LTS) – sudo‑rs becomes the sole default; transition period extends to Ubuntu 26.10.

Users can revert to classic sudo via update-alternatives --config sudo, though it is discouraged without a specific need.

Community feedback – original sudo maintainer Todd Miller participated in sudo‑rs code review and back‑ported discovered issues to classic sudo, demonstrating collaborative progress rather than abandonment. Both versions can coexist and benefit each other.

5. Practical guide for Ubuntu 26.04

5.1 Check the current sudo implementation

# Show sudo version and implementation
sudo --version
# Example output on Ubuntu 26.04
Sudo‑rs version 0.2.13
Configure options: --prefix=/usr --sysconfdir=/etc

# Verify the binary points to sudo‑rs
ls -l $(which sudo)
# lrwxrwxrwx 1 root root 7 Mar 20 10:00 /usr/bin/sudo -> sudo‑rs

5.2 Common configuration scenarios

Scenario 1: Password‑less execution of specific commands

# /etc/sudoers.d/deploy
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart mysql

Scenario 2: Time‑restricted sudo usage – sudo‑rs itself does not implement time limits; they must be enforced via PAM.

# /etc/sudoers.d/time‑limited
admin ALL=/usr/bin/apt, /usr/bin/dpkg
# sudo‑rs does not support time limits directly; configure via PAM.

Scenario 3: Dedicated sudo logging

# sudo‑rs logs to syslog by default
journalctl -t sudo
# Or configure rsyslog
if $programname == 'sudo' then /var/log/sudo.log

5.3 Troubleshooting

Problem 1: sudoers entry not taking effect

# Verify syntax (sudo‑rs checks automatically)
sudo -l
# Show detailed error for a specific user
sudo -l -U username

Problem 2: PAM authentication failure

# Inspect PAM configuration files
ls -l /etc/pam.d/sudo*
# Example sudo PAM service files
auth required pam_unix.so
account required pam_unix.so

Problem 3: Switching back to classic sudo

# Install classic sudo (provided as sudo‑ws)
sudo apt install sudo‑ws
# Switch alternatives
sudo update-alternatives --config sudo
# Choose /usr/bin/sudo‑ws

6. Future of sudo

6.1 Upcoming plans for sudo‑rs

Short‑term (2026‑2027): complete AppArmor and SELinux integration, improve error‑message clarity, optimize performance to match classic sudo.

Long‑term vision: explore configuration models beyond traditional sudoers, develop more flexible privilege‑management paradigms, deep integration with container technologies.

6.2 The Rust‑ification wave in Linux

Completed Rust rewrites:

ripgrep (grep replacement)

exa (ls replacement)

bat (cat replacement)

fd (find replacement)

Projects in progress:

uutils‑coreutils (Rust implementation of GNU coreutils)

rustls (TLS library replacing OpenSSL)

zbus (modern D‑Bus implementation)

7. Summary of technical benefits

Security – fundamental elimination of memory‑safety bugs.

Maintainability – code size reduced by ~70 %, easier to audit.

User experience – password feedback with asterisks and clearer error messages.

Future extensibility – modern architecture supports new feature development.

8. Further reading

Official sudo‑rs repository: https://github.com/trifectatechfoundation/sudo-rs