Ubuntu 25.10 Introduces sudo-rs: Rust-Based sudo Replacement

Hot Ubuntu Updates are here! Ubuntu 25.10 Introduces sudo-rs. Ubuntu is set to make a significant change in its upcoming 25.10 release by adopting sudo-rs as the default sudo implementation. This move involves replacing the traditional sudo command with a Rust-based alternative. The primary goal is to bolster system security and reliability by leveraging Rust’s memory safety features. Let’s delve into the details of this transition to a memory-safe sudo as the default in Ubuntu.

For many years, the sudo command has been a cornerstone of Linux systems, providing users with the ability to execute administrative tasks. However, its implementation in the C programming language has made it susceptible to vulnerabilities, particularly those related to memory management. The new sudo replacement, known as sudo-rs (a Memory-safe sudo), is written in Rust, a programming language renowned for its safety and performance characteristics.

By adopting sudo-rs, Ubuntu aims to mitigate the risk of memory-related security issues and create a more secure environment for its users. This is a forward-thinking step in enhancing the overall robustness of the operating system.

Memory-safe sudo to become the default in Ubuntu

Why Rust-based sudo?

Rust’s design philosophy prioritizes the prevention of common programming errors that often lead to security vulnerabilities. These include issues like buffer overflows and null pointer dereferencing. Rust’s strong safety guarantees make it an excellent choice for system-level programming, where security is paramount.

By transitioning to Rust-based utilities like sudo-rs, Ubuntu is proactively improving the security and stability of its operating system. This move reflects a commitment to providing a more secure and reliable platform for its users.

What Does sudo-rs Mean for Ubuntu Users?

The transition to sudo-rs is designed to be seamless for most users. The new implementation aims for compatibility with existing workflows, ensuring that users can continue using sudo as they always have. The key difference lies behind the scenes, where the improved safety and reliability of Rust provide enhanced security. The adoption of Ubuntu 25.10 Introduces sudo-rs should be invisible to most users, except for the added security it brings.

Ubuntu 25.10: The Test for sudo-rs

Before making sudo-rs the default in the next Long Term Support release (Ubuntu 26.04), Ubuntu is testing it in Ubuntu 25.10. This allows Ubuntu to gather feedback and work with the developers to further improve sudo-rs. Specific improvements and considerations include:

Ensuring compatibility with older systems: Supporting older systems is crucial to prevent issues when running newer Ubuntu containers on older hosts. Without this support, sudo functionality could be disrupted, leading to significant problems.
Thorough testing: Ubuntu is ensuring that all tests for sudo-rs run correctly on their system. This proactive approach helps identify and resolve any issues early in the development process.

Final Words

The move to sudo-rs is more than just replacing one program with another. It demonstrates Ubuntu’s commitment to long-term security and building a resilient system. While Ubuntu isn’t abandoning C programming entirely or rewriting everything in Rust, choosing to update such a fundamental tool highlights the importance of safer, stronger, and more reliable systems in the future. The release of Ubuntu 25.10 Introduces sudo-rs is a step towards that safer future.

You can find more detailed information on the Ubuntu Community Discourse.

Please subscribe to us on Facebook, X, and YouTube.

You may also like to read the following articles:

Introduce Ubuntu 25.04 Plucky Puffin

Discover Differences: Ubuntu 25.04 vs 24.04

Install Ubuntu 25.04 on VMware Workstation

Initial Settings After Installing Ubuntu 25.04

Alternative Solutions to Enhance Sudo Security

While transitioning to a memory-safe language like Rust, as demonstrated by sudo-rs, is a significant step forward, other approaches can also enhance the security of privilege escalation mechanisms like sudo. Here are two alternative methods, along with explanations and code examples where applicable:

1. Fine-Grained Access Control Lists (ACLs) with Capabilities

Instead of granting full root privileges with sudo, ACLs combined with Linux Capabilities offer a more granular approach. ACLs allow you to define specific permissions for users or groups on individual files or directories. Linux Capabilities then enable you to grant specific privileges to executables, allowing them to perform certain privileged operations without requiring full root access.

Explanation:

The core idea is to avoid the "all or nothing" approach of sudo. Instead of allowing a user to run any command as root, you restrict their ability to only execute specific, necessary operations. This dramatically reduces the attack surface if a vulnerability is exploited. If a user can only run a specific program with specific capabilities, an attacker gaining control of that program is limited in what they can do.

Example:

Let’s say you want to allow a user to restart a specific service, but you don’t want them to have full root access.

Create a script to restart the service:

#!/bin/bash
# /usr/local/sbin/restart_my_service.sh
systemctl restart my_service

Set the file permissions:

sudo chown root:root /usr/local/sbin/restart_my_service.sh
sudo chmod 755 /usr/local/sbin/restart_my_service.sh

Grant the CAP_SYS_ADMIN capability to the script: This capability allows the script to perform many system administration operations, including restarting services.
```
sudo setcap cap_sys_admin+ei /usr/local/sbin/restart_my_service.sh
```
Set ACL permissions to allow a specific user to execute the script:
```
sudo setfacl -m u:myuser:--x /usr/local/sbin/restart_my_service.sh
```

Now, the user myuser can execute /usr/local/sbin/restart_my_service.sh and restart the service because the script has the CAP_SYS_ADMIN capability, but they cannot perform other administrative tasks requiring root privileges. They only have the minimum required permissions. To verify the capability:

getcap /usr/local/sbin/restart_my_service.sh

This should output something similar to: /usr/local/sbin/restart_my_service.sh = cap_sys_admin+ei

Benefits:

Reduced Attack Surface: Limits the potential damage from exploited vulnerabilities.
Principle of Least Privilege: Adheres to the security best practice of granting only the necessary privileges.
Auditing: Easier to track which specific privileged operations are being performed.

Drawbacks:

Complexity: Requires careful planning and configuration of ACLs and Capabilities.
Maintenance: Needs ongoing monitoring and adjustments as system requirements change.

2. Using a Restricted Shell with Limited Command Set

Another approach is to use a restricted shell environment in conjunction with a limited set of approved commands. This involves creating a special user account with a shell that restricts the available commands to a predefined list.

Explanation:

This method creates a "sandbox" for users who need to perform certain privileged actions. The restricted shell limits their ability to execute arbitrary commands, preventing them from performing unauthorized tasks. This provides a layer of security by isolating the user within a controlled environment.

Example:

Create a new user account with a restricted shell (e.g., rbash or a custom script):
```
sudo adduser limiteduser
sudo chsh -s /bin/rbash limiteduser
```

Create a directory for allowed commands:

sudo mkdir /home/limiteduser/bin
sudo chown limiteduser:limiteduser /home/limiteduser/bin

Create symbolic links to the allowed commands within the user’s bin directory:

ln -s /usr/bin/ping /home/limiteduser/bin/ping
ln -s /usr/bin/traceroute /home/limiteduser/bin/traceroute

Modify the ~/.bashrc (or equivalent) for the restricted user to further limit the environment:

# ~/.bashrc for limiteduser
PATH=/home/limiteduser/bin
export PATH
unset DISPLAY
unset EDITOR
unset vi
alias ls='/bin/ls --color=auto'

Now, when the limiteduser logs in, they will only be able to execute the ping and traceroute commands. Any attempt to run other commands will be blocked by the restricted shell. Using aliases can help to lock down the environment further.