Memory-Safe Sudo To Become the Default In Ubuntu 116
Longtime Slashdot reader RoccamOccam shares a blog post from the Trifecta Tech Foundation, a nonprofit organization that creates secure, open source building blocks for infrastructure software. The foundation is also the developer behind Sudo-rs. From the report: Ubuntu 25.10 is set to adopt sudo-rs by default. Sudo-rs is a memory-safe reimplementation of the widely-used sudo utility, written in the Rust programming language. This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. [...]
The decision to adopt sudo-rs is in line with Canonical's commitment to Carefully But Purposefully increase the resilience of critical system software, by adopting Rust. Rust is a programming language with strong memory safety guarantees that eliminates many of the vulnerabilities that have historically plagued traditional C-based software. Sudo-rs is part of the Trifecta Tech Foundation's Privilege Boundary initiative, which aims to handle privilege escalation with memory-safe alternatives.
The decision to adopt sudo-rs is in line with Canonical's commitment to Carefully But Purposefully increase the resilience of critical system software, by adopting Rust. Rust is a programming language with strong memory safety guarantees that eliminates many of the vulnerabilities that have historically plagued traditional C-based software. Sudo-rs is part of the Trifecta Tech Foundation's Privilege Boundary initiative, which aims to handle privilege escalation with memory-safe alternatives.
That's cool! (Score:2)
Although I would like sudo that is formally verified, not simply memory safe. Maybe something worth doing in Ada/SPARK.
As long as.... (Score:5, Funny)
...it can still make me a sandwich we're good.
Re: (Score:2)
It's the real sudo's memory unsafety (forgetting how many sandwiches it's made and who for) that allows for this. Don't worry, you can use sudo-rs to run sudo.
Re: (Score:2)
It will be a rusted sandwich. ;)
Re:As long as.... (Score:5, Funny)
There's nothing "safe" about going to your wife and saying "sudo make me a sandwich".
Please explain⦠(Score:1)
Could someone explain to a ânon-coderâ(TM) what this means in laymanâ(TM)s terms please. ;)
Re:Please explain⦠(Score:5, Insightful)
Someone re-wrote a piece of code that already worked into their preferred language so that they could trumpet their accomplishment.
Re: (Score:2)
into their preferred language
And, of course, that preferred language happens to be Rust.
Re: (Score:1)
I doubt it matters what language it is. ... for no real reason. ... okay, why not.
People complain about Java, C#
I mean complaining about Lisp
Lucky that I do most in Dart. Looks like a Java/C#/C mix ... just does not have real pointers to mess everything up, to bad! No one complains about Dart ... yet.
Re: (Score:1, Informative)
Copy/Pasted from a Google search
Rust ensures memory safety primarily through its unique ownership and borrowing system, which is enforced by the borrow checker during compilation. This system ensures that each value has a single owner at any given time, preventing issues like dangling pointers and use-after-free errors.
Here's a more detailed breakdown:
1. Ownership:
Every value in Rust has a single owner. When the owner goes out of scope, the value is dropped (freed). This prevents double-freeing and oth
Re:Please explain⦠(Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
Which really leads one to ask... if you're not a programmer... don't really know what you're talking about... why are you here cheerleading for something?
It doesn't require unsafe {
Rust ensures memory safety primarily through its unique ownership and borrowing system, which is enforced by the borrow checker during compilation. This system ensures that each value has a single owner at any given time, preventing issues like dangling pointers and use-after-free errors.
i.e., the usage of std:: is unsafe. You cannot pretend that code outside of the uns
Re: (Score:2)
A I find what you are saying to be a misleading understanding of "unsafe". "unsafe" has a specific meaning as a keyword in the Rust language. Which is to do with relaxing the checks on the use of pointers. Such "unsafe" operations, as defined in the Rust language, are absolutely required in any language. Without them it would be impossible to do any I/O. Clearly denoting such unsafe operations in the source code is very valuable feature.
Re: (Score:2)
A I find what you are saying to be a misleading understanding of "unsafe".
Not in the slightest.
"unsafe" has a specific meaning as a keyword in the Rust language.
Yes, it allows memory-unsafe operations.
Which is to do with relaxing the checks on the use of pointers.
Part of it, yes.
Such "unsafe" operations, as defined in the Rust language, are absolutely required in any language.
This is misleading. You're trying to imply that since they're "required" (they're not, really), but let's pretend they are- that all usage of them in std:: is required (they aren't)
In some cases, they're unavailable, like FFIs- but these are small and narrowly defined.
In some cases, it's because the language lacks primitives to do things you want to do in assembler. This is avoidable, but only if you want to sacrifice the functio
Re: (Score:2)
Re: (Score:2)
root. changing access levels. Avoiding restrictions.
Re: (Score:2)
Slashdot doesn't do UTF-8. Yeah, I know... pathetic.
Re: (Score:2)
Re: (Score:1)
That is not UTF-8, that is an (Windows) extended ASCII character. Not the same as UTF-8 :P
Re: (Score:2)
Re: (Score:2)
ö.
If I watch the post go through (via FireFox network debug window), it is indeed UTF8 encoded, not ASCII.
Something within Slashdot is converting the codepoint.
Re: (Score:2)
Yes it does. It just filters out non-ASCII codepoints to prevent site takeovers using Unicode control characters.
There's lots of attacks you can do with Unicode including abusing the RTL override characters and applying excessive amounts of decorations to a character. Since the number of codepoints that can be abused keeps increasing it's hard to keep a blacklist up to date so it's got a whitelist of ASCII printable characters only.
Unicode support has been
Re: (Score:2)
I've seen it accept my UTF-8 happily, but an ASCII char ends up in the comments. Whitelist for CP conversion makes perfect sense.
Welp (Score:3)
This is probably gonna break some of my 20-year-old plus scripts
Re: Welp (Score:2)
I'm thinking it's in addition to sudo; able to change back to sudo as default
Re: (Score:2)
Meh. The big distros have already deprecated sudo in favor of policykit (which has not yet been re-written in rust).
Re: (Score:2)
Sun tried that 25 years ago and even today it is hard to find correct examples of how to create the configuration to make it useful. There were a lot of good things in Trusted Solaris that never got used even in most places that decided they needed the "Trusted" version.
Re: (Score:2)
That's nice. Meanwhile it works fine here in Linux. Most modern desktop environments use it for doing administrative tasks. Very similar to macOS.
Re: (Score:2)
Yes, it may break things [github.com], although it's drop-in compatible for the subset of sudo functionality it implements. I'm not sure if Ubuntu will migrate everyone by default on upgrade, but they'll almost certainly keep the original sudo as an option for people that need it.
Re: Welp (Score:2)
Re: (Score:2)
Rust isn't supported on as diffusive an architectural list as linux and gcc are.
Re: (Score:2)
That is true of course. A problem that is likely to be fixed when the GCC guys get their Rust front end working.
Re: (Score:1)
Re:Welp (Score:4, Informative)
How do you think permissions are obtained in linux?
Sure, some things can be snuck around with capset(2), others can be handled with fine-grained filesystem permissions, but otherwise, you need to come in as root and drop perms.
Are you suggesting that we should just suid the script?
Re: (Score:2)
there are very few things that definitively need root
That's just... well, wrong, lol.
and using sudo to get root permissions is overkill in almost every situation.
As is this.
I would love to see you administrate a linux machine without elevating privileges.
Do we count cheating via PolicyKit? (i.e., delegating the privilege escalation?)
Re: (Score:3)
They're not obtained with sudo.
No, they're obtained with the ways I listed, including uid 0. The safest way for an unprivileged process to get to uid 0 from an unprivileged process is sudo.
"root" is the sum of the capabilities you can obtain with capset(2). A thread that drops all capabilities could not do any root things, despite its 0 uid.
Wrong.
Flat out fucking wrong, lol.
tl;dr; sudo is a piece of shit and anybody still using it in 2025 is an idiot.
And your ignorance makes you fucking dangerous.
Re: (Score:2)
"root" is the sum of the capabilities you can obtain with capset(2).
By all means, do quote what on God's Green Fucking Earth led you to think that, though ;)
You have no fucking idea what you're talking about.
A process running as root that has dropped its capabilities from its bounding set is just like running as "nobody".
Ya- a process running as nobody that can read and write from /etc/shadow, a 0640 root.root file, lol
Dude, seriously, get the fuck out of here.
Great, but ... (Score:3)
Avoiding dangers of dependency explosions (Score:3, Interesting)
This blog post discusses the risk of depending on dozens of unstable packages, not uncommon for programs written in modern languages:
Sudo-rs dependencies: when less is better [memorysafety.org]
The sudo utility represents a critical privilege boundary, so it should be memory safe. [...] Ruben Nijveld from the Tweede golf team offers his perspective here on one of the greatest challenges we faced when developing software that can be widely adopted: Rust crate dependencies.
When sudo-rs development started, we added several dependencies using Rust's crates ecosystem to quickly ramp up development. During development we accrued approximately 135 transitive (direct and indirect) dependencies. Once this was identified, we managed to reduce our total dependencies down to three. In this blog, we explain why and how we did this.
The remaining dependencies are the core crates libc, glob, and log.
Re: (Score:3, Informative)
$ ldd `which sudo-rs`
linux-vdso.so.1 (0x000072fbe0db3000)
libpam.so.0 =>
libgcc_s.so.1 =>
libm.so.6 =>
libc.so.6 =>
Re: (Score:2)
Nice, but that is not what the OP was asking about.
Re: (Score:1)
The immediate implication of my comment is that no "Rust environment" needs to be installed for the sudo-rs executable to function. I guess you could consider statically linked code an "environment", but at any rate it doesn't pull in a bunch of dependencies from the package system that you would get with e.g. a Java or Node application.
Re: (Score:2)
To nitpick a little bit: a Java Application, would come with its own Java runtime.
That is what the word "Application" implies.
So: again nothing to install. It comes with what ever package manager you are choosing - automatically - or is inside of the package - preferably.
Re: (Score:2)
You still missed the point. If you want to edit the source and patch sudo-rs yourself, you've got to install all the rust dependencies. That was his point. Yet another development environment, along with the security issues that relying on third-party crates brings with it.
Whereas most of us already have the basic C compiler and includes installed by default.
Honestly this is one reason I have zero interest in downloading neat projects written in rust from github to try out on my computer.
Re: (Score:3)
I got two different answers, both useful.
1) For someone who is unfamiliar with Rust, it appears that it can be statically linked to existing libraries. Good ... but that opens up the question of how secure a sudo.rs executable can be if an attack surface exists in someplace like libc.so (the 'old fashioned' C implementation). If I understood this response incorrectly, then:
2) A project to 'Rustify' any existing executable will be an involved job. Here (https://www.memorysafety.org/blog/reducing-dependenci [memorysafety.org]
Re: (Score:2)
it appears that it can be statically linked to existing libraries. Good
Not good.
std:: is full of unsafe code. Statically linked binaries will never have patched std:: applied to them until they are recompiled.
I'm sure this will be shipped with a dynamically loaded, and more importantly- able to be updated- libstd-rust. There have been security vulnerabilities caused by unsafe code in std:: before, and there will be again.
Re: Great, but ... (Score:2)
Re: (Score:1)
Actually that was what OP asked about.
As OP did not understand his own question.
So, to answer your hidden question and to expand on the answer you answered to:
there is nothing to install to run sudo-rs, as everything that is not on your system is hard linked and every *.so it needs: is already on your system.
And that would be/should be a no brainer but alas, people in our times know nothing about "how computers work".
Is the claim that current sudo is not memory safe? (Score:5, Informative)
Re:Is the claim that current sudo is not memory sa (Score:4, Interesting)
It wasn't memory safe in 2021 [mitre.org]. Maybe that was the last latent memory safety problem and no subsequent ones will ever be introduced, but I wouldn't count on it.
Re:Is the claim that current sudo is not memory sa (Score:5, Informative)
Re: (Score:2)
Yes, "unsafe" code blocks which show up a lot in low level libraries (in this case the standard library) are still subject to memory errors. It's still enormously helpful in practice that most application code (e.g. the ad-hoc string parsing code in the sudo CVE) can be categorically excluded from containing memory errors, leaving a smaller surface area to audit and harden.
Re: (Score:3)
Re: (Score:2)
While the separation of safe and unsafe is useful, I think this is overblown. First, it is not just about memory safety. In an application like sudo you would also need to screen all code anyway for logic errors. Second, the clear separation between unsafe and safe is not always that clear, e.g. the safety of an unsafe block might also depend on correctness of the safe part, even when the actual memory safety issue is then in the unsafe block.
Re: (Score:2)
Holy fucking irony, "We're sorry but the CVE Website doesn't work properly without JavaScript enabled. Please enable it to continue." What ass clownery is this? Luckily MITRE is actually a website [mitre.org].
Re: (Score:2)
(and yes, I do realize they are going to close down mitre.org at some point because they are in the process of moving to cve.org... what either incompetent or evil dickheads)
Re: (Score:2)
what either incompetent or evil dickheads
I think both can be true :/
Re: (Score:2)
it is just not written in a memory-safe language
The current trend is to say that "it is just not written in Rust", which is equivalent (according to the propagandists).
Re: (Score:3)
Re: (Score:1)
Considering that sudo only does one single thing: starting a process with elevated privileges ... ...
Who the funk cares if it terminates a split second later or crashes with a segvault
It is not so that it opens a hand full of ports and waits for "legitimated input" and due to a "buffer overflow" starts doing illegit things.
Re: (Score:2)
You don't want a buffer-overrun there.
But the attack-scope is very limited, I agree with that.
Re: (Score:2)
Appearance is what matters in a Post Truth world. That is why you are not hearing any discussion of whether or not they use any "unmanaged" (is unmanaged really not a word?!) code in the final executable.
Don't care (Score:3)
I use su like god intended.
Re: (Score:2)
So, sudo su me.
Re: Don't care (Score:3)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
I use su like god intended.
Me too. The thing is, users who are not Linux-savvy tend to use 'sudo' because they were told to. Then they tend to use it all the time, even when it shouldn't be used.
Re: Don't care (Score:2)
Re: (Score:2)
Of course not.
The ancient and still trusted solution is to:
- Create a new user account for that, give the password to that account to the user in question.
- Create a shell script that performs the actions without introducing security issues.
- Put that script as the login shell for that user.
Q.E.D.
Sudo is for whimps.
Trying to rewrite it to be memory safe is like mandating safety goggles for chainsaw operators.
Will it make it safer to use it? Sure, slightly.
Was it safe to begin with? Not really, handling ch
Re: (Score:2)
Shell scripts without security issues are impossible.
That is why it is a no, no!, No!, NO! to write setuid shell scripts.
Modern shells can mitigate a little bit ... but only a little bit.
The correct way if a user wants to do something that requires root: he writes a ticket.
And you do it. If the "you do it" requires more than a single command: you write a script.
Commit the script, and put the commit log (or even the script) into the ticket when you close it.
Usually in a sane organization, the version control
Re: (Score:2)
Shell scripts without security issues are impossible.
That depends. Do they need to take input? Then yes, they are impossible. Otherwise, they are very possible. Simply don't use any variables. For any complex problem this is not feasible. For just running a command as a specific user, it works fine.
Re: Don't care (Score:2)
Furthermore, how do you handle the password for the user you created? Maybe you have secured root but you can't just trust a team of people to share a single pas
Re: Don't care (Score:2)
Your analogy suggests you do not have much experience with chainsaws.
Re: (Score:2)
Within the specifications were: "This one command needs to be run as root".
You're going to create an unprivileged user, create a shell script that does this thing... and then what.... suid it?
And you think that is.... less of a chainsaw than giving that user access to that one script within
You're scary.
made a better doohickey (Score:2)
But why not just get rid of the doohickey completely, and waste less of your time and cognitive ability on something you don't need in the first place.
Re: (Score:2)
If you're claiming that sudo is unnecessary, you should probably also give some hints about how one could accomplish the tasks people currently use sudo for, without using some variant of sudo.
Re: (Score:2)
I look forward to never having to drop privs again!
Or I wonder... if you just have no fucking idea what you're talking about.
Re: (Score:2)
Re: (Score:2)
Before anyone comes bitching about this being MIT (Score:3)
... Please remmeber that GNU is free (as in fredom) to fork sudo-rs, relicense it as GPL and mantain the fork, meanwhile, if one forks GPL code, one is NOT FREE to re-license it.
So, if one is worried about GNU/Linux (or Ubuntu, specifically) being less GNU and less GPL by the minute, then get forking, re-licensing and maintaining.
This in not a ploy to make linux "less free", is just linux evolving into a new codebase, in a more modern and (allegedly) more safe language.
JM2C
YMMV
Rust == memory safe automatically? (Score:2)
Re: (Score:2)
should be
> "Memory-Safe" Sudo To Become the Default In Ubuntu
or rather
> Rust Sudo To Become the Default In Ubuntu
Why? (Score:2)
Let me quote many C and C++ programmers ... (Score:2)
"Rust will never be a major part of linux."
"There is no way the linux people will allow rust."
"Rust is still just a toy, entirely not proven, it will be decades before it is trusted."
"Rust is still very much in beta, and not really used in production."
Re: (Score:2)
"Rust is still just a toy, entirely not proven, it will be decades before it is trusted."
"Rust is still very much in beta, and not really used in production."
C++ is a toy used in production, producing decades worth of defective code, it will never be trusted.
After 3 months of learning Rust, my impression is that Rust's beta is much better than C++'s maturity. Take operator overloading as an example, for types like polynomials that use heap allocation. Rust does this correctly, so in
Re: Let me quote many C and C++ programmers ... (Score:2)
Re: (Score:2)
The & symbol in Rust is not a "dereferenced pointer." &a + &b is not pointer arithmetic. &a means that you use "a" by read-only reference (without copying it or modifying it). Therefore, it makes perfect sense to use it for arithmetic, even though it looks a bit strange. The operation will use the existing values without copying them or modifying them, and produce a new value. There is a complication, that the result of the computation is a value, not a reference, so to cover all situati
Re: (Score:2)
The & symbol in Rust is not a "dereferenced pointer."
Isn't in C, either, as I suspect you know
Re: (Score:2)
* is the dereferencing operator.
Dereferenced pointer would be:
int a = 0;
int *p = &a;
p = address_of_a
*p = value of a
^ that is the dereferenced pointer. no problem doing arithmetic with those.
&a + &b would be pointer arithmetic.... and something you would never want to do.
I can think of no situation where you'd want to add 2 variable addresses together. Offsets- ya... complete addresses? no- that sends you into
Re: (Score:1)
The destructor will deallocate it.
If you write the code in a way that the variable never gets "out of scope", then the destructor is not called.
If that is your question.
Seems you made your code artificial complex that standard C++ is not able to deallocate unused variables/memory.
What the funk that has to do with "operator overloading" is beyond me.
Re: (Score:2)
They're talking about intermediates. Scope isn't an issue.
However- I don't know how he has had this problem, as intermediate destructors are absolutely called once the intermediate is no longer needed.
Literally the only way I can imagine such a thing happening, is if the class has no destructor... and uhhh, that's hardly C++'s fault
Re: (Score:2)
That would mean the "intermediate" allocates extra memory via new/malloc etc. and has no destructor to release it.
Correct- he stated heap allocated.
Destructor won't cut it.
The C++ Rule of 5 applies.
You'll need at minimum a move assignment and copy constructor- and that's only if elision works. Since you shouldn't rely on that unless you're very familiar with all of the rules, you should have a copy constructor, a copy assignment constructor, a move constructor, and a move assignment constructor.
Since they stated "heap allocated", they're doing something like this:
class test
{
private:
int *val;
public:
test(int cval = 0)
{
val = new int;
*val = cval;
}
~test()
{
delete val;
}
test operator+(test const& other)
{
test ntest;
ntest.val = new int;
*ntest.val = *other.val + *val;
}
}
The "gotcha" is that the destructor for the immed
Re: (Score:2)
Can this be done with C++? I tried decades ago and gave up.
C++ has always been able to do this. I've been using C++ since the mid 1990s and it's always been able to do that.
Re: (Score:2)
Example:
creating t1
(test)constructor called for 0x16bb8eb98
creating t2
(test)constructor called for 0x16bb8eb88
creating t3
(test)constructor called for 0x16bb8eb84
creating t4
(test)constructor called for 0x16bb8eb80
PRE: t4 = t1 + t2 (should see 1 intermediate created and cleaned up)
(test)constructor called for 0x16bb8eb7c
(test)destructor called for 0x16bb8eb7c
POST: t4 = t1 + t2
PR
Re: (Score:2)
Re: (Score:2)
One of the things that is cool about Rust is precisely that you don't need to know about elision and other magic tricks C++ does. C++ requires way too much... acquired defensive knowledge to protect you from it, lol
Priorities (Score:2)
So Canonical has broken a bunch of functionality that used to work perfectly well in older Ubuntu versions. Do they focus on fixing it? Do they instead add new functionality to make things more user-friendly and generally better? No, they change sudo, which works absolutely fine, at least I've never had a single problem with, to its rewrite in Rust. Because it's a cool new thing.
Honestly, up until recently Ubuntu was the default Linux distro for me, now I'm not so sure. It's not an option to replace it righ
It says it is fixing stuff (Score:2)