Why do we need sudo-rs?
Posted by bankroll5441@reddit | linux | View on Reddit | 203 comments
I finally got around to updating one of my home servers from Ubuntu server 25.04 to 25.10. I put it off for a while as I couldn't figure out why my tun mods were not persisting across reboots and finally set out to correct that yesterday.
Nonetheless, everything was smooth with the upgrade, I fixed the tun issue (was related to ubuntu using copymods for raspberry pi's), no issues. Though I ran my biweekly updates via Ansible and found that privilege escalation was failing, despite sudo working just fine with the same exact key the controller uses for Ansible. I looked into it and found that Ubuntu decided that sudo-rs should be the default going forward.
Now, I looked into it, but am not a dev. I don't do server administration on an enterprise level. I do not understand why we need a "memory safe" implementation of sudo, and why Canonical seems to be the only ones implementing this. Can someone please explain in laymens terms why we need a rust re-write of sudo and how it's beneficial to end users/administrators?
ElePHPant666@reddit
Memory safety is good but I will add that rust rewrites won't fix over complicated and bad design. A lot of sudo exploits have been from parsing and logic errors, not memory safety. Personally, I'd rather see a rewrite of doas in rust or just better privilege escalation tools that don't require suid (run0, capsudo).
Kevin_Kofler@reddit
Funnily, postmarketOS has just recently announced its switch from doas to sudo-rs only 1½ years after switching from traditional sudo to doas.
ElePHPant666@reddit
Understandable, the doas port for linux isn't maintained anymore and postmarketos supports both systemd and OpenRC so they could only use run0 on one flavor. Personally on my systems I've been migrating from doas to run0.
AverageComet250@reddit
I thought alpine Linux maintains a version since they use it as standard? Or is that version not usable on other distros?
ElePHPant666@reddit
Sort of, we have a few patches for system integration and security but otherwise use https://github.com/Duncaen/OpenDoas which hasn't seen a commit in 4 years.
ClassAbbyAmplifier@reddit
opendoas is a strict linux port of the OpenBSD doas, which also hasn't had significant changes in a similar timeframe. it's not dead.
AverageComet250@reddit
Yeah I noticed that there was little activity recently when I went to install it from pkgsrc on netbsd, but also noticed that a similar port named doas was available with a more recent commit although similarly unmaintained.
I just assumed that there was a maintained version somewhere that wasn’t available for netbsd.
Although opendoas is a very simple program, unless major CVEs are found, is active maintenance really necessary?
Computer-Nerd_@reddit
What about using group priv's and dojng away with su escalation entirely for installation? The whole point of su for anything other than daemons & ports is side-stepping security in favor of false lazyness (i.e., not an attributes of good orogrammers).
JustBadPlaya@reddit
I mean, Rust does have significantly better parsing capabilities than C simply because not having to juggle pointers (and higher abstraction level in general) help with that a lot
Unicorn_Colombo@reddit
Why is everyone scared of pointers?
Dwedit@reddit
If you have completely static memory, or other memory that will never ever be freed, then pointers become okay.
Otherwise, pointers are a dangling address that corresponds to something that can be deallocated in the future.
There are ways to design things that you don't need to use raw pointers. One way is to have a reference-counted object or array, and a "lock" function. Call "lock" when you want a raw pointer, then only use that pointer within a small code block, never storing that pointer anywhere outside of the small code block. That will avoid dangling pointers.
PurepointDog@reddit
It's not that we're scared of them. It's that we realize we're human.
Humans are decent at getting things to work, but bad at fully addressing the state space of every possible variation of ways things can go wrong. And historically, a lot of things have gone wrong in raw pointer usage
JustBadPlaya@reddit
Pointer juggling without very good static checks opens you up towards a wide variety of bugs. C, having insanely low abstraction level, forces you to work with raw pointers all the time, and since we're only human, such checks are forgotten all the time
You simply can't have something as safe, fast and convenient as Clap or Serde in C, you must choose two at best and one on average
felipec@reddit
You can have memory safety in C.
the_abortionat0r@reddit
This brain rot needs to stop.
In rust you literally can't do memory insecure code without explicitly trying to.
In C it's willy nilly as long as your code is good enough to complie.
It really annoying hearing bottom feeders trying to tell programers they should work harder because some rando has a religious fetish for older languages for no reason other than being old.
teleprint-me@reddit
C safety options are disabled by default for backwards compatibility.
Its in there, its just off by default and most C programmers are against turning it on by default.
Some consortium members have argued in favor on enabling it in new compilers, but the push against that is strong while argument for it is weak.
It could be improved, but due to reasons Ive stated, it hasnt been implemented.
So, calling it "brain rot" is fairly strong language that expresses more of a level of contempt more than level headed input.
pitiless@reddit
Even when enabled the guarantees provided are a joke compared to rust's offering, but they're also not used by writers of c programs...
This is why your comment is a joke.
teleprint-me@reddit
Its obviously not a joke and Im not laughing. They should be enabled by default. Rust still requires unsafe pointers and suffers from logic bugs which is more likely in a rewrite that is done in a clean room fashion to strip GPL licensing.
JustBadPlaya@reddit
ok first of all - no GPL stripping here. At all
To the actual point - yeah, Rust does have unsafe code, and some pointer handling even. After all, both are a necessity when FFI and kernel-level calls are involved. The difference between C and Rust in this regard is that Rust's unsafe keyword allows you to properly move unsafe concerns to the edges of the application. In C, you're working with pointers pretty much all the time - not having actual safe references is a big factor in this, as is the generally non-existent abstraction level. This makes proving memory safety move from a problem for the edges of the program to a centrepiece of it all
felipec@reddit
It's funny they call us "religious fetish" for stating factually true claims, and downvote facts just because they don't like. That's precisely what a religiously motivated person would do.
teleprint-me@reddit
Willfull ignorance is a form of stupidity and is unfortunately very common.
felipec@reddit
None of what you've said contradicts my factually true claim.
You can dislike it all you want, it's still 100% true.
SaltDeception@reddit
With way more effort, sure. Rust memory safety is automatic and enforced by the compiler. In the age of LLM discovered exploits, I’d much rather my security enforcement layer be guaranteed memory-safe with Rust than placing my trust in the devs to have done it correctly every single time with C.
ArrayBolt3@reddit
There's also Fil-C.
Business_Reindeer910@reddit
at great runtime cost.
SaltDeception@reddit
I just had an interesting thought experiment. Enforcement happens at runtime, so if memory is corrupted the process aborts. So let’s say hypothetical malicious code embeds a service that’s purpose is to corrupt the memory of a hypothetical Fil-C sudo binary. Sudo then aborts before elevating access, creating a denial of service for elevation. Now let’s say the hypothetical malicious service is tailored to only corrupt memory for operations that could detect or remove it, and that it targets other methods of elevation as well. Could you not create a malware persistence vector leveraging Fil-C’s enforcement mechanism?
Business_Reindeer910@reddit
I don't know enough about how fil-c actually works to say. I've just seen the the benchmarks.
felipec@reddit
And you seriously think people have not spent that effort for an important security program such as
sudo?Also, you are wrong. It's significantly easier to secure an existing program than completely rewrite it in Rust. Way way easier.
SaltDeception@reddit
Those were not claims I made. How can I be wrong about them?
The comment I replied to was along the lines of “Memory safety can be achieved in C”
Do you dispute that, in general, it is less effort to achieve memory safety in C than Rust? Or that with C memory safety requires vigilance and that Rust does not require that same vigilance?
felipec@reddit
You made the claim that ensuring existing C code is memory safe is "way more effort" than writing it in Rust, did you not?
That is irrelevant because we are not talking about a hypothetical situation in which the C code doesn't exist. The topic of this post is sudo-rs, we are talking about C code that already exists.
You are completely ignoring the opportunity cost between the two actual options:
SaltDeception@reddit
No, I did not. I made a general statement that more effort is required to make C code memory safe. I did not make the claim or even imply that rewriting is Rust is less effort than making existing C code memory safe.
It may be irrelevant to you, but the comment (I’m assuming yours?) did not imply that (or any) context.
This context was not carried down to the comment. Reddit comment sections often diverge from the main topic.
Yes I am because that was not the discussion I was engaging in. Sometimes the cost is worth it, other times not. If memory safety is the only goal, perhaps it’s misguided.
felipec@reddit
So your comment is completely irrelevant to the topic: "Why do we need sudo-rs?".
SaltDeception@reddit
Yes? Again, that wasn't the implication of the specific conversation I was engaging in. I've explained pretty exhaustively the context of my statement. There's really no point in getting this worked up about it.
felipec@reddit
I am not "getting worked up", I am stating the fact that this is irrelevant for the topic at hand.
Additionally it's irrelevant for 99% of the Rust versus C debates because in the overwhelming vast majority of cases the C code already exists.
SaltDeception@reddit
k
Dangerous-Report8517@reddit
Or even just using doas instead of sudo (eg Alpine Linux uses doas by default) since the structural simplicity improves its security much more than memory safety would
TRKlausss@reddit
True, but it helps with maintainability.
You got a parsing error -> want to modify your program -> introduce a memory safety error.
Doing it in Rust helps with the later. But of course, logic errors will always be there.
scoobybejesus@reddit
doarse, perhaps
StatementOwn4896@reddit
Bloody hell
Klapperatismus@reddit
capsudo is a very small tool that can be audited easily. The problem with it is that its setup can’t. It’s poking peepholes everywhere by design.
zig7777@reddit
Oof the thought of running a server on something other than an LTS gives me anxiety as a professional sysadmin
But also, no we don't need it from a user/admin standpoint. Rust rewrites seem to be more for the maintainers and the ease of writing good code going forward. I'm generally not against that. When they're released they sure as hell should just be drop in replacements though. It breaking ansible is not great.
bankroll5441@reddit (OP)
I have 3 servers on Ubuntu, 2/3 are on LTS. The others are on a mix of Debian and NixOS stable. Tbh, I accidentally flashed the non-LTS version by accident and was too lazy to change it. It does some very basic, non-critical tasks so I wasn't super worried about it.
And yeah, by all means if it makes it easier on maintainers, I totally get that and support it. But the ansible got me too, I haven't looked into whether or not support has been added in newer Ansible versions I'm on 2.16.3
martinjh99@reddit
Can you not put a symbolic link into bin as sudo?
sudo-rs -> sudo
Would that work with ansible?
LinuxSBC-Anna@reddit
You misunderstand.
sudo-rsis a package that provides thesudocommand. The issue with Ansible is some discrepancy between the behaviors of coreutils sudo and uutils sudo.CarpenterElegant7365@reddit
sudo isn't part of coreutils as well as sudo-rs isn't part of uutils* 🤓
LinuxSBC-Anna@reddit
Oh, you're right. Sorry, I didn't realize that. Thanks!
martinjh99@reddit
Ah got it! Thanks!
dev_vvvvv@reddit
Rust rewrites seem to seldom be done by the original maintainers. coreutils and sudo rewrite being some big-name examples.
I would say it's a combination of
Sharp-Debate-523@reddit
Maybe because the core Linux utilities were written decades ago
OkSignificance5380@reddit
Which means they are battle hardened, with bugs having been fixed years ago.
RoomyRoots@reddit
That has always been something that bugs me off and in a horrible way. That and many of the rewrites being MIT.
pezezin@reddit
The original sudo is not a GNU project, and has been distributed under a MIT-like license since 1999.
ArjixGamer@reddit
Sudo rewrite is overseen by the sudo author though
Also, Rust is not only about memory safety, it is much more easier to write production grade code in Rust than in C.
Majorly thanks to the great stdlib, as well as the ecosystem having great libraries like tokio, trace, etc
The macro system is wonderful, and you can also do metaprogramming (using build.rs file).
The memory safety is great and all, but even w/o it I find it superior to C++
proton_badger@reddit
There can be many reasons; I did some rewrites simply to learn Rust, as I usually do with new languages. It’s nice to have a well defined thing to reimplement when learning a new toolchain.
Sudo-rs is a rewrite maintaining a similar license as the original, but apart of safety it’s also to get a more maintainable code base. Only Todd Miller really thoroughly understands the sudo code which is also why Sudo-rs has his support. This has led to benefits both ways as it has led to bug fixes in sudo, akin to how coreutils/uutils both contribute to one test suite.
ydieb@reddit
If you haven't noticed, people as a whole end up rewriting everything in everything for fun, this is not remotely rust specific.
It is just that uutils for example ended up with canonical going "hey, this can actually be a good replacement for the gnu utils, maybe it should".
zig7777@reddit
Hmm the licencing is something I hadn't considered but makes a lot of sense. That's gotta be a big part of it.
The code security scanner we use at work added scanning for "undesirable" licenses as a feature recently, and management had us set that up. Which makes sense from a business point of view, but isn't something distro design should be catering to.
Business_Reindeer910@reddit
if you're selling support contracts for your distro, then you absolutely MUST design around that !
froli@reddit
Corporate or corporate-backed distros are made to cater to businesses... Not surprising to see Canonical push for MIT licensed software over GPL.
ArjixGamer@reddit
I have a VPS running Arch
rdcldrmr@reddit
wait until you find out about how many (known) kernel vulnerabilities never get their patches backported to "LTS" distros, and it'll give you a lot more anxiety.
bankroll5441@reddit (OP)
Ubuntu's LTS versions use supported LTS kernels which do receive security patches
rdcldrmr@reddit
check https://kernel.org and look at the branch of your ubuntu kernel. is it that version? no. ubuntu and others selectively backport some fixes, but leave many security fixes at the door.
the reality is that, if they were backporting security fixes, you'd have a new kernel update every week.
loozerr@reddit
My server runs arch :)
FriendlyProblem1234@reddit
There are nearly no rewrites.
Those are all separate projects. sudo-rs is not related to sudo. uutils is not related to coreutils.
This is different people starting a new project in a language they like. Exactly like Linus did in 1991 when he started working on a new kernel.
The only actual rewrite I am aware of is fish, where the original developers actually rewrote their own project from C to Rust (and other projects that added some new Rust modules / subsystems to their codebase, like Firefox or the Linux kernel).
And then some distributions might adopt those projects. After all, distributions are not bound to use exactly the same components. Some choose glibc, some choose musl, some choose uclibc... Some choose systemd, some choose OpenRC, some choose Runit... Some choose KDE, some choose Gnome, some choose XFCE... Some choose sudo, some choose sudo-rs, some choose doas...
safety-4th@reddit
because 0days do not belong in sudo
Kevin_Kofler@reddit
Because of "let's rewrite everything in Rust" fanaticism.
(Ubuntu is not the only distro shipping sudo-rs though. At least postmarketOS is moving to it for the next release.)
the_abortionat0r@reddit
I love how there's objective benefits to using rust but emotional lunatics freak out and call the functional crowd "fanatics".
You can bounce around in your rubber room while the rest of the world moves on.
Kevin_Kofler@reddit
There are also objective drawbacks of rewriting working code from scratch just because you do not like the programming language. E.g., sudo-rs has fewer features than the original sudo (but the developers market that as a "feature", pointing out that this means the attack surface is smaller, which is true, but with that argument, the smallest attack surface is not having a computer at all).
db48x@reddit
Simply having more features is not always a strong reason to choose one alternative over another. What about distros that don’t use sudo at all? Are they doing something wrong? What about sudo itself, which replaced older programs that did the same job?
xnfra@reddit
The corpos want to kill the GPL so they can just steal code without contributing legally.
db48x@reddit
While that may be true, sudo is not licensed under the GPL: https://www.sudo.ws/about/license/
Kidev@reddit
That’s what I thought when I noticed the “surge” of MIT like licenses. However, have you heard about the malus.sh project? It seems that it is a joke, but the idea of clean room engineering copies of open source projects to wipe the license is viable. That makes me very worried for GPL and co, as I’m a die hard advocate for those.
icehuck@reddit
We need a rewrite so that canonical can control the license. It's the same reason there is a core-utils rewrite. It's all about controlling the license.
FriendlyProblem1234@reddit
sudo and sudo-rs licenses are nearly identical, both permissive, and grant the same rights. Maybe actually look into this, instead of parroting easily-disprovable nonsense.
icehuck@reddit
Who owns the copy write on the rust version? It's definitely not Todd Miller the current dev of sudo , nor is it Robert Coggeshall or Cliff Spencer.
FriendlyProblem1234@reddit
What is a copy write?
And how does this related to the fact that sudo and sudo-rs have the same license? If they have the same license, then this "rewrite" (which is not a rewrite, it is a separate project developed by independent developers) cannot have happened "so that canonical can control the license".
mikeymop@reddit
I am curious.
What exactly failed in your ansible that worked with sudo but not sudo-rs?
I haven't really looked deeply into it an assumed much of the relevant parts of its cli were in parity with the original.
I figured I'd switch when its more mature, but being able to anticipate some issues like you've had would make it easier for me to guage its maturity.
bankroll5441@reddit (OP)
From my understanding it's the way it prompts for authentication, the become plugin in Ansible sees it as a failed authentication attempt
https://github.com/trifectatechfoundation/sudo-rs/issues/1461
https://github.com/ansible/ansible/issues/85837
kqvrp@reddit
That's a bad design by sudo-rs then. It should try to be as identical to sudo legacy as possible to avoid such things.
Daktyl198@reddit
Sudo-rs purposely avoids certain insecure features of sudo, while maintaining as much compatibility as possible otherwise.
Megame50@reddit
No, the authors just don't know how sudo works, because they can't read a man page.
Daktyl198@reddit
The authors of sudo-rs work closely with the maintainer of C sudo. They know how it works better than you do.
Megame50@reddit
That's not what the maintainer of C sudo says on his website:
Conversely, sudo-rs states this in their FAQ:
I feel this is a pretty flowery way to write "he commented on our github issue" (on a topic that specifically concerned OG sudo behavior). The authors have every incentive to inflate his involvement for their own clout. It's clear they want to be seen as trustworthy and meticulous, but aren't willing to just let the work speak for itself, so would rather write blogs about sudo "problems" that are actually just them failing to read the man-page.
I've nothing against a rust rewrite of sudo, but the sudo-rs project repeatedly fails to inspire confidence.
Daktyl198@reddit
Sudo-rs has contributed back to the original Sudo with both code and tests. There are other places where they are more explicit with the collaboration. Just because you want to be delusional doesn’t change fact. You’ve got a really weird chip on your shoulder regarding sudo-rs.
If you have a specific issue with the project on a technical level, I’d love to hear it. Because so far nothing you said has been useful at all.
TerribleReason4195@reddit
Canonical is trying to go full on rust. They are trying to rewrite everything in rust in Ubuntu, whether you like it or you do not. I do not care, I don't use Ubuntu.
bboozzoo@reddit
they as in who? sudo-rs - random foundation, uutils-coreutils - random project, where exactly is the affiliation you're implying?
TerribleReason4195@reddit
>Canonical is trying to go full on rust.
I am trying not be rude, but can't you assume?
bankroll5441@reddit (OP)
That's the primary reason for the switch from what I understand. Happy cake day!
benny-powers@reddit
They're opposed to the GPL
JustBadPlaya@reddit
sudo is ISC, sudo-rs is MIT+Apache
zackel_flac@reddit
We don't, it's a waste of time and energy but some people have time to lose.
Maybe-monad@reddit
They just need something to put on CV
MouseJiggler@reddit
When it reaches full feature parity - we can compare and decide what we prefer. Until then - we don't.
proton_badger@reddit
I don't think you should expect Netscape LDAP or sendmail support in sudo-rs.
MouseJiggler@reddit
No sendmail support is a dealbreaker for many to this day.
thaynem@reddit
Using a "memory safe" language means it is less likely to have certain classes of bugs. In a program like sudo, those bugs can lead to privelege escalation (i.e. you can get root when you aren't supposed to).
sudo-rs also has less features than sudo, so there is less attack surface (although that can be a problem if you need those features).
On the other hand, sudo-rs is pretty new code that hasn't been as tested in the "real world" as the OG sudo, so there may be new bugs lurking in it.
bankroll5441@reddit (OP)
I think this is where my biggest surprise is. The project is 3 years old(?) and it seems a little hasty to be replacing something that has been battle tested for decades.
proton_badger@reddit
"battle tested" is one of those terms that sounds good, really good but it just sets up a mirage, an ideal. In reality sudo is intricate code only the author understands thoroughly and has vulnerabilities on regular basis. This is why the original author supports sudo-rs, to get safer but also more maintainable and approachable code base before he retires.
Our community use lots of components that have been rewritten multiple times, in many languages or in the same language. It's a long tradition and this time it happens to be in Rust.
New versions always bring paper cuts though, some of which will only be found once in production for a while. So difficult to say when is a good time to ship it but shipping first in a non LTS release is a good choice. In the meantime use the orig sudo if you like.
mrtruthiness@reddit
Of course that's why the person installing can choose whichever (sudo or sudo-rs) they want at least in 26.04.
Severe_Stranger_5050@reddit
if you need more features, just stack them
"sudo sudo-rs" :P ;)
/jk
TampaPowers@reddit
And it's coming in at the worst time where LLMs pump out poor quality code and hunt for exploits constantly. Making waves on how safe Rust supposedly is paints a giant target on such things as well. It's rather risky to adopt early, but it seems Canonical loves bugs cause they been happy to accept a lot of them lately.
Great-TeacherOnizuka@reddit
doaslazer---sharks@reddit
Why do we need a more secure tool for doing privilege escalation? Is that really your question? https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714
Bruflot@reddit
Five of those were memory related. How many new CVEs do you think we’re going to get some new vulnerabilities in sudo-rs? I’d take battle tested software over a Rust rewrite any day of the week.
KittensInc@reddit
The problem is that your "battle-tested" advantage goes out of the window the moment you actually have to maintain the codebase: even the most highly-paid C developers are unable to avoid accidentally introducing new memory vulnerabilities.
In the end you're left choosing between a handful of CVEs right now due to the rewrite and virtually none afterwards, or a constant stream of CVEs because people keep making oopsies in C: do you want long-term security or short-term security?
Dangerous-Report8517@reddit
A fair sentiment in general, but at least in this case sudo-rs has input from the original author of sudo, and all of that battle testing sounds good until you remember that it keeps failing those tests over and over because it's a complex tool iteratively built to work in an environment that's very different to modern Linux - building a new tool from the ground up with input from the original creator but also new eyes is an opportunity to streamline things and make it much more robust
Farados55@reddit
bugs in new software doesn't mean it's not better in many ways to the old software. That's kind of a silly way of looking at things.
No-Dentist-1645@reddit
The entire point of rewrites is that Rust code is not only guaranteed to be "memory safe", but also easier to maintain. Sure, some bugs will occur, but on the long run, it will be easier to fix and reduce overall bugs.
Pandoras_Fox@reddit
given how the vuln-finding bots are going, I'd say it's not unlikely to find more memory corruption/bugs in ye olde sudo, but also.... it seems eminently fixable, yeah.
bankroll5441@reddit (OP)
If the main reason is related to memory but there has only been two memory related CVE's in sudo in the past 9 years that doesn't seem like it warrants a full rewrite and implementation to me. I am not saying I'm right or trying to be picky, I'm genuinely curious.
HighRelevancy@reddit
Bugs in sudo mean that any malware/actor that gets into an unprivileged process (either a clumsy user running something bad, or a bug in a dumb web-app that does RCE) can be daisy-chained into a full root access.
Is it not obvious why you would want the safest possible implementation?
bankroll5441@reddit (OP)
I am not against security, another commenter explained the memory safety that helped me understand why its important.
I don't think we can assume that sudo-rs is vuln free. It is still a very young project at 2 years old to be implementing at such a high level.
mrtruthiness@reddit
If not now, when?
Users/admins have the choice to use sudo or sudo-rs (both are available) ... just like coreutils/uutils.
And somebody who is running non-LTS on a production server is a bit hypocritical talking about "young code" in production.
bankroll5441@reddit (OP)
I mentioned this in another comment but this server is doing some very non-critical tasks in my homelab. This is not a production server for work and installing a non-LTS version of ubuntu server was actually a mistake that I never corrected. All of my other servers are either running Ubuntu LTS, Debian or NixOS stable.
I guess I'm just moreso surprised that it's being implemented in Ubuntu before Fedora and RHEL derivs, NixOS, etc.
mrtruthiness@reddit
It's (sudo-rs) not default in NixOS, but you can easily enable it. The same is true for Fedora since Fedora 38.
On Ubuntu, the first LTS with sudo-rs as the default will be 26.04 and, of course, you can easily use the "traditional sudo" instead. sudo-rs only started being default in 25.10 and, in some sense, Ubuntu has some advantage in that they get 6 months of non-LTS use to see if it's appropriate for an LTS. And they deemed that it was.
Real-Abrocoma-2823@reddit
Everyone, let's wait another 10 years before using sudo-rs!
Result: No one tests or uses sudo-rs
HighRelevancy@reddit
No, writing in rust doesn't automatically make it vulnerability-free. What it does is make it exceedingly unlikely to write vulnerabilities in non-obvious ways to do with memory silliness. Memory safety is like half of all serious vulnerabilities.
Rust gives lots of other useful tools to prevent errors like a much smarter type system too.
bankroll5441@reddit (OP)
That does make sense, I honestly had no idea that memory was such a common factor in vulnerabilities before making this post. So is rust safer because of the way values can't be "shared" and only "borrowed"? But C allows anything to use a value even if its being used by something else?
HighRelevancy@reddit
It's value lifetime issues, yes, that's part of it. It's also the more abstract stuff like giving you better tools so you don't have to do silly memory hacks in the first place. Lots of other people have covered that whole thing better than I can.
AnsibleAnswers@reddit
Overflows are also memory vulnerabilities. So, memory safe languages could effectively have prevented 2/3 of the CVEs for sudo in the last 9 years. Each 0 day is a major to do.
DL72-Alpha@reddit
Technically speaking information security requires constant vigilance while the hostile party only needs to get lucky once.
That said, There's a better way to harden a more mature solution than to invent a brand new solution nobody has found vulnerabilities for *yet*.
QuaternionsRoll@reddit
Both are happening at the same time right now. What’s wrong with that?
gwildor@reddit
when im wearing my security hat, the 'ive been doing it this way for 20 years' are my favorite guys to replace.
m0ntanoid@reddit
oh no, 6 vulns where 2 is duplicated and only 3 kind of priv escalation. And all of that in 10 years period.
Of course we need to code sudo in rust. Result will be much better than decades of coding original sudo.
My fucking god... How many problems in future we all will have because of fucking rust coders who can't sleep without using fucking rust in projects where everything already was okay. This reminds me of trump who re-opens this strait after it was already open since Christ birth.
snail1132@reddit
Comparing rewriting programs in rust to the disaster that is the hormuz strait right now is actually braindead
m0ntanoid@reddit
I didn't say any word you just put in my mouth.
NW3T@reddit
makes me think anti-rust coding is somehow related to political propaganda - the rust coders i know are chill. Rewriting a working project in a new language for no reason is a bad idea.
Rewriting a security critical piece of software where half the CVEs have been memory corruption related to remove an entire class of problem - probably smart if you were gonna make some big new rust system anyway.
Agreed that existing systems should just continue to patch their C based core utils unless they have some reason to switch over.
libra00@reddit
6 of those in 10 years seems to be a fairly small number? *shrug*
dmknght@reddit
CVE detail is the weird choice of showing vulnerabilities =)) at least use cve.org
Great-TeacherOnizuka@reddit
doasbankroll5441@reddit (OP)
Can you please explain why doas is better? Is it because of the small codebase and low complexity?
theunquenchedservant@reddit
This source is also, I believe, inaccurate. It's showing 0 CVEs in 2025, but a Stratascale researcher found two CVEs in 2025
https://www.sudo.ws/security/advisories/chroot_bug/
https://www.sudo.ws/security/advisories/host_any/
VividGiraffe@reddit
License. Memory safety is the argument, removing GPL is the goal.
DerekB52@reddit
The NSA and security experts are pushing for the adoption of memory safe software. Technically a non memory safe sudo is exploitable to a program that could somehow edit a computers ram to point sudo to a malicious chunk of code to run.
But Canonical has gone all in on rust and is rewriting a bunch of stuff. This is done for memory safety, but also because rust is a growing language with a strong userbase and a lot of developers who want to work on Linux and Linux software, want to use Rust. To tap into that market of developers, some entities are being very friendly to rust. Which I think is good.
If there is any benefit to end users/admin it is going to be the fact that rust can attract devs.
Dangerous-Report8517@reddit
I wouldn't cite the NSA's peak as indicative of something being a good thing, they've done some good things with e.g. SELinux but they're also responsible for some pretty sinister activity like various attempts to undermine cryptographic security standards. Independent security researchers, absolutely, but the push for memory safety is good despite the NSA's involvement, not because of it
Fohqul@reddit
I don't believe Canonical is rewriting anything, just switching to packaging Rust alternatives
SaintEyegor@reddit
And possibly trying to get rid of gnu licensed code that keep them from world domination.
FriendlyProblem1234@reddit
I know you are being sarcastic, but just to be clear: sudo is licensed under a permissive license nearly identical to MIT: ISC.
Those who are enraged now by sudo-rs license should have been enraged about sudo license for the past 40 years.
LigPaten@reddit
Don't you understand! This is a long con! Surely Microsoft forced the creater of sudo to license it under a permissive license so they could EEE in 2026 with a. Rust version!
Is this conspiracy good enough?
Business_Reindeer910@reddit
all their own projects use the GPL with CLA.. which means they don't even have to comply with the GPL.
mina86ng@reddit
Any program is exploitable to a program that could edit a computer’s RAM. It’s also not true that programs written in non-memory-safe languages automatically have vulnerabilities.
bankroll5441@reddit (OP)
I'm not too well versed on the security side of things, how realistic is an attack via memory exploitation? I guess the memory safe stuff is what I don't understand. I've seen it mentioned a lot as a major benefit of rust but it's never clicked with me
I understand the reach that rust has and that it opens up the space for more development, that is certainly a good thing
Kidev@reddit
Simplifying, but: basically C lets you a lot of freedom in writing to memory. This is nice, but also dangerous, as if you did not 100% made sure that everything that is written in memory is verified and safe, you can get abused. A classical example is you let a user write in memory 5 characters. But you don't check that it's actually just 5 characters. The user can write 100 characters, and the 95 extra will get written in the program memory. Being clever about that is what most memory attacks are.
Rust gives you less freedom. It makes sure the kind of errors I mentioned earlier with the characters will never happen due to some clever compiler tricks. However, it is not magically safe either. There can be other kinds of attacks beside memory attacks.
bankroll5441@reddit (OP)
This is a very good explanation and helps me visualize why it's important, thank you!
Azazeldaprinceofwar@reddit
To add on to a little bit of “but does this actually happen” side of your concerns. The answer is that these sort of attacks aren’t super common but are always the most severe because once you can edit memory you’ve completely circumvented any system of trust the program operates on. The famous xz utils back door from a few years ago relied on an illegal rewriting of memory while the linker was attaching dependencies to attach malicious code for example. Another example is the Mythos BSD exploit was able to remotely take root control of open BSD by overrunning a memory buffer. In fact project glass wing reports the majority of 0-day exploits found by mythos are related to memory safety issues. So there is good reason to think it’s worth rewriting security critical programs in rust. Now for you personally there’s surely no issue switching back to sudo as there’s no known issues with it. It’s more we just understand its architecture is principle is vulernable to these sort of detrimental attacks and we’d like that to not be true.
Lcd_E@reddit
While attacks might not be super common, memory related vulnerabilities are, in fact, (very) common.
As a sysadmin maintaining infra of 2k+ machines I'd rather spent time on something else than patching yet another "use-after-free" high/crit vulnerability. Memory safe languages prevent a lot of those and others.
There's quite nice article, although related to android https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1
Business_Reindeer910@reddit
it's very realistic. There have been many attacks that exploit bad coding related to memory usage on programs. C does not protect from this in any way.
Sweaty_Nectarine_585@reddit
did you read canonical reasoning? what do you not understand?
LumenAstralis@reddit
As was famously said, "it is like cancer."
julioqc@reddit
wtf is that nonsense
bankroll5441@reddit (OP)
explain?
julioqc@reddit
that whole sudo-rs replacement. I get why but its a total cluster fuck of a deployment. I'm glad I retired from sysadmin...
the_abortionat0r@reddit
You never did sysasmin though...
julioqc@reddit
sure thing mom 🙄
donut4ever21@reddit
I'm here with my popcorn bucket 🍿. Hi.
mrlinkwii@reddit
do we really need any software ?
legrenabeach@reddit
Stuff like that are the reason I switched my servers from Ubuntu to Debian.
egorf@reddit
Same here. I was furious when they changed sshd to systemd socket activation and I could stand sudo-rs as long as I can remove it first thing after installation.
Rust coreutils was the last straw.
TampaPowers@reddit
I'm in the exploration phase of that, cause yeah Canonical is really dropping the ball on a lot of things and I have had a lot more trouble the last 5 years than I had the 10 prior.
legrenabeach@reddit
Last time I had a Ubuntu laptop was several years ago, then I discovered Ubuntu forced software to be installed via snap even through the application centre (so I thought I was getting deb and it was getting snap) with peformance degradation, so I ditched it for Debian even for the laptop.
bankroll5441@reddit (OP)
Yeah, I honestly don't run much on this machine and was already contemplating moving it to NixOS because of the mod issues. Within a desktop environment, sure it doesn't matter as much, but I don't want something as heavily integrated as sudo changing on my servers just because rust
TryptamineEntity@reddit
Or RHEL derivatives
archdane@reddit
I've been using `run0` (man). Do you need the complexity of `sudo` on a single user system?
It was fixed a while back in `run0` that you don't need to re-authorize for each command run in a shell session. The expiration time is configurable through polkitd.conf file.
CypherAus@reddit
We don't NEED sudo-rs - little benefit for a whole lot of risk
DodgeFox970@reddit
Not sure, I use Doas with my NixOS KDE plasma desktop even if I typed Sudo(muscle memory) it'll automatically execute it as Doas.
Mysterious_Pie7377@reddit
Because a bunch of pretend wannabe developers who think writing something in a training wheels language is the equivalent of being an actual good programmer in a language that has actual flexibility and usefulness took over Linux with the "BUT IT'S SAAAAAFE" bullshit argument. You can write horrible, unsafe code just fine in your training wheels language, too, and it's more likely that you will if you ignorantly rely on Baby's First Language to save you from your own mistakes.
FriendlyProblem1234@reddit
We do not *need* a memory safe implementation of sudo, like we did not *need* a monolithic Unix-like kernel back in 1991. Someone thought it was a useful / interesting / viable project, and they implemented it in the language of their choosing.
And once a software exists, if other people also think it is useful / interesting / viable, they might start using it, and the project might eventually get momentum.
Why is it so enraging that a specific distribution adopts this as default sudo implementation? Should all distributions use exactly the same components? Should we complain about Alpine because it does not use systemd or glibc? Should we complain about Gentoo because it does not use apt or dpkg?
If not, why should we complain about Ubuntu because it uses sudo-rs?
pancakeQueue@reddit
My hypothesis is Canonical wanted to change the software license to not GNU.
FriendlyProblem1234@reddit
sudo is licensed under ISC, which is basically the same license as MIT.
cyb3rofficial@reddit
Brother is summoning the rust cultists, protect your self, otherwise be canceled on x!
pancakeQueue@reddit
I’ll glaze Rust all day if I have too, but replacing sudo with Rust I think is a false flag to get the license changed. However if Anthropics Mythos is as good as they say it is, maybe we should expedite to memory safer languages before it finds every zero day.
JustBadPlaya@reddit
sudo-rs (potentially) replacing sudo the original literally cannot be license-related, as both projects have effectively the same license - sudo is ISC-licensed, whereas sudo-rs is MIT (which is historically just cleaned up ISC)
Do your research before posting nonsense
pancakeQueue@reddit
Lmao, you comment before you edited was funnier.
JustBadPlaya@reddit
What the fuck are you talking about with this license shit, sudo is ISC. Please do some fucking research
bankroll5441@reddit (OP)
lol you're not wrong. I don't mind the downvotes at the end of the day all I wanted was a better understanding of the "why"
I already uninstalled sudo-rs...I would rather retain my automated management than have to remote into an extra server when it's not necessary
cyb3rofficial@reddit
The why is much more deeper than what people think. It goes beyond memory safe.
It's not really because it's memory safe, it's down to people bringing their own political beliefs into open source, people fighting like younglings, attitudes, hate lists, so on. Canceling lists, dislike lists, etc.
Once you actually start digging into it, looking up names, their connections, you'll realize how stupid everything is, why it is. We end users are just caught in the cross fire.
divad1196@reddit
Rust is not "just" for memory safety. It's a powerful language. Implementation becomes easier and reduce the risk of bugs.
But memory safety is always good to have. Imagine if a buffer overflow could grant any user root privileges.
JustBadPlaya@reddit
A big part of sudo-rs as a project is similar in scope to smth like doas - have a minimal privilege escalation tool that only does what it's supposed to. sudo has a LOT of functionality that nobody ever uses, part of which are just ancient practices. Removing those with sudo-rs cuts the attack surface by an order of magnitude
Hari___Seldon@reddit
So the implied expectation of your description and question is that Canonical should maintain two separate utilities to perform the same function? If it's something you don't need, then don't worry about it. It's just above your paygrade. Say thank you for the free software and enjoy all the benefits it brings for you.
bankroll5441@reddit (OP)
You are certainly implying and assuming here. I don't think there's anything wrong with asking people more knowledgeable than myself to help me understand the implementation of rust in a critical program. I show appreciation to the FOSS community through monthly recurring donations to several projects, maintaining packages and being an advocate for the space.
No, I was asking rewriting sudo in rust is worth it. A lot of smart people here were able to explain why it's worth it. Thank you for your contribution.
felipec@reddit
We don't need a reimplementation. It's that simple.
It's perfectly possible to write memory safe C code.
Rust advocates seem to believe rewriting in Rust will get rid of all the bugs. It won't. Only more bugs will be introduced.
the_abortionat0r@reddit
It's so cool you have no programming knowledge but have such strong religious opinions on the topic. YOURE SO SMART!
pfassina@reddit
Some people will say that it is because of memory safety, others that it is because of the GPL license.
The memory safety argument is to prevent bugs and security risks.
The GPL license is so that they can charge money.
Tireseas@reddit
Ask Todd Miller. He's collaborating with the sudo-rs guys.
Flash_Kat25@reddit
A big part of it is that sudo is extremely bloated. Simply reducing the functionality is not really possible with an existing project. A complete rewrite does have that freedom however.
smallgovernor@reddit
Code of sudo is terrible. Like, it's really really bad C. If you know C please try to read a bit of it. It's really bad. I had to make a sudo addon at work, and it was the worst coding experience I've had ever.
No wonder it just keeps spamming CVEs whenever it gets bored.
I will never use sudo willingly again. run0, doas, sudo-rs, anything is better than sudo.
VivaPitagoras@reddit
Because that's the beauty of FOSS and a group of people thooght it would be a good idea oto create a sudo version in rust.
m3xtre@reddit
beauty of foss is when I license-wash foss software
m3xtre@reddit
license-washing
FortuneIIIPick@reddit
IDK but I'll continue using sudo unless they end up removing it, then I will remove Kubuntu/Ubuntu and switch to something else, maybe plain Debian across the board, server and desktop. And in that event, I will of course stop all advocating for Kubuntu/Ubuntu.
fellipec@reddit
Need is a strong word
No-Dentist-1645@reddit
Sudo is literally the most powerful command on your computer. It can allow you to run any command with the same privilege level as root, i.e the "administrator" of your computer. If someone manages to run arbitrary commands via sudo due to something like a buffer overflow, they could theoretically do anything to your computer. And you're saying you don't get why this command needs to be memory safe?
bakaspore@reddit
It's not just memory. sudo-rs also intentionally keep some insecure by default and rarely used features / options out of scope. You can go and count how many CVEs in sudo are basically impossible to happen in sudo-rs, I think it's more than half of them.
doas and run0 are also good options but sudo-rs is a drop in replacement of sudo that just works.
minneyar@reddit
sudois one of the most powerful tools on your system. It lets normal users run things as root. A single buffer overflow or out-of-bounds error on it could allow anybody to run any command as root. It's a huge potential security vulnerability, and it makes sense to write it in a language that prevents those sorts of memory issues in the first place.Another good alternative to
sudoisrun0, but that's a systemd thing and a lot of people don't like systemd. So, might as well write a version ofsudoin rust.void4@reddit
Cause Sovereign Tech Fund had some spare (German taxpayers') money to dump on open source.
So, to take your hands on these money, you need some spare open source projects. If you have no ideas and no skills for such projects, what would you do? Indeed - you take some existing project and RiiR.
Everyone else should just use doas.
zlice0@reddit
sudo is easily the best memory safety case of the rust version system utils.
theres still edge cases that have to be 're-discovered' as far as i understand it because of licensing. still the ability to royally fuk things up. logic bugs and loops are still possible. memory leaks are still possible in certain use cases. and being rust and most likely interacting with a libc(written in...c) there will be rust
unsafekeyword usage which nukes the rust compiler safety more or less for parts of the code.Entire-Cress-4148@reddit
we dont
Cautious_Read_7713@reddit
tbh the timing seems weird to me too. like sudo has been working fine for decades and suddenly we need memory safe version? i get that rust prevents buffer overflows and stuff but sudo isn't exactly known for having major security issues recently.
maybe it's just canonical trying to be ahead of curve but feels like solving problem that doesn't really exist for most people. your ansible breaking is probably exactly why this rollout feels premature - if it's not 100% compatible then what's the point in rushing it to default?
Peetz0r@reddit
This is hugely underestimating the security landscape in general.
Sudo has quite a number of serious vulnerabilities (source). The only reason it isn't known for that is because almost all non-trivial software has bugs, and many bugs are security issues, and quite a bit of those are serious.
Usually the impact is limited. Partly because they get fixed quickly enough, partly because security comes in layers, and partly because you and me aren't targets for aimed attacks. But that doesn't mean that trying to prevent vulnerabilities isn't worth it.
Rewriting existing C programs in rust doesn't make then anywhere near 100% secure. And the process not perfect, re-implementing complex software is an opportunity to introduce new bugs (or re-introduce old bugs) and it takes a lot of effort. And then you have to maintain it. But when done properly, it does eliminate an entire category of bugs. So, like almost everything in engineering, it's a trade-off. But for security-critical software like sudo, it often does make sense.
daemonpenguin@reddit
There have been a few vulnerabilities found in sudo, or exploits which used elements of sudo, in just the past few years. There is definitely good reason to look at alternatives.
hotchilly_11@reddit
there was a CVE for sudo as recently as 2023 relating to memory corruption. Are you fine with the risk of another one being discovered?
bankroll5441@reddit (OP)
yeah I'm just not understanding any tangible, real word benefits of it that warrant the implementation
four_reeds@reddit
If for no other reason, it's that one last chance to make sure that you really meant to type that command to wipe "/".