Imagine a crucial security component in your operating system suddenly developing cracks. That's precisely what happened with Ubuntu 25.10's shiny new 'sudo-rs' – but thankfully, the vulnerabilities were identified and patched up with impressive speed! This incident highlights the ongoing balancing act between innovation and security, especially when introducing new technologies into core system functions.
Just recently, Ubuntu security advisory USN-7867-1 sounded the alarm, revealing a pair of security loopholes within the freshly integrated 'sudo-rs' command. You might recall that The Register first covered the arrival of this Rust-based sudo in Ubuntu 25.10 back in May of this year. It's important to note that this 'sudo-rs' is a distinct project from the other Rust-based component in 'Questing Quokka,' which involves Rust replacements for the traditional GNU coreutils. The coreutils are basic utilities like 'ls', 'cp', and 'mv' that are foundational to a Linux system.
Now, let's be clear: security vulnerabilities are never a good thing, particularly when they crop up in a core system tool responsible for authentication and elevated permissions. However, in this case, the discovered holes were relatively minor and would have been challenging to exploit in a real-world scenario. Think of it like finding a tiny crack in a dam – concerning, but not immediately catastrophic.
For context, the classic C version of sudo is a venerable tool, dating back to 1980 according to the project's own history. Even The Register's FOSS desk encountered it in the first public beta of Mac OS X way back in 2000. Ubuntu has championed the sudo command – and actively discouraged the use of the all-powerful 'root' account – since its very first release, 4.10 'Warty Warthog'.
The new 'sudo-rs' implementation, available on GitHub, represents a complete rewrite of the original. Project lead Marc Schoolderman from the Trifecta Tech Foundation even presented a talk on the subject at the recent Ubuntu Summit, titled 'Sudo-rs and beyond.' The Register attended this talk and engaged in conversation with Schoolderman afterwards, gaining valuable insights directly from the source.
But here's where it gets controversial... Given the diverse opinions within the Linux community regarding the Rust programming language, both positive and negative, Schoolderman emphasized that neither of the discovered issues stemmed from memory safety concerns – meaning they weren't directly related to Rust itself. Memory safety is a key feature of Rust, aiming to prevent common programming errors like buffer overflows. The fact that these vulnerabilities were unrelated to memory safety might surprise some, sparking debate about the true benefits and risks of using Rust in core system components. What's your take on this? Let us know in the comments!
Despite the limited scope of these bugs, they did carry security implications, making it crucial to address them promptly. Sharing information about vulnerabilities, along with their fixes and underlying causes, is vital for promoting awareness and preventing similar issues in the future. Schoolderman also shared that the team had backported these security fixes to the 'stable' version of 'sudo-rs' in Debian, simplifying things for downstream packagers. This is a fantastic example of how the open-source community collaborates to ensure widespread security.
Since the release of 'Questing Quokka' almost exactly a month ago, this marks the second time that the new Rust components have come under scrutiny from bug hunters. Back on October 23rd, Julian Andres Klode reported a date-handling bug in the Rust coreutils. Details are available in Canonical's Bug #2127970. The date -r $FILENAME command, designed to display the last modification time of a file, was malfunctioning and returning the current date instead. This seemingly small issue had significant consequences, as it broke automatic updates by preventing accurate file age checks. And this is the part most people miss...
Digging deeper, it turns out that the Rust commands silently accept the same switches as their C counterparts from the GNU coreutils. This behavior, while common in packages that replace older tools, can sometimes lead to unexpected issues. Think of it like the Postfix 'sendmail' command, a simpler replacement for the classic 'sendmail'.
Fortunately, the Rust date issue did not result in serious system failures. A standard update process would install the fixed 'date' command, resolving the problem. In contrast, the 'sudo-rs' vulnerabilities were treated as security issues, triggering a full Coordinated Vulnerability Disclosure process. Schoolderman noted that the team was pleased with the smoothness of the process and the collaborative interactions with other open-source stakeholders. This highlights the importance of having well-defined procedures for handling security vulnerabilities in open-source projects.
Ultimately, these incidents underscore the value of interim Ubuntu releases. They provide a platform for testing new tools in the real world, allowing the community to identify and address unforeseen issues. Schoolderman concluded that this approach is essential for ensuring the stability and security of the operating system in the long run.
So, what do you think about Ubuntu's embrace of Rust in core system components? Are the potential benefits worth the risks? And how do you feel about the speed and transparency with which these vulnerabilities were handled? Share your thoughts in the comments below!
