'sudo' and 'su' Are Being Rewritten In Rust For Memory Safety (phoronix.com) 143
Phoronix reports:
With the financial backing of Amazon Web Services, sudo and su are being rewritten in the Rust programming language in order to increase the memory safety for the widely relied upon software... to further enhance Linux/open-source security.
"[B]ecause it's written in C, sudo has experienced many vulnerabilities related to memory safety issues," according to a blog post announcing the project: It's important that we secure our most critical software, particularly from memory safety vulnerabilities. It's hard to imagine software that's much more critical than sudo and su.
This work is being done by a joint team from Ferrous Systems and Tweede Golf with generous support from Amazon Web Services. The work plan is viewable here. The GitHub repository is here.
"[B]ecause it's written in C, sudo has experienced many vulnerabilities related to memory safety issues," according to a blog post announcing the project: It's important that we secure our most critical software, particularly from memory safety vulnerabilities. It's hard to imagine software that's much more critical than sudo and su.
This work is being done by a joint team from Ferrous Systems and Tweede Golf with generous support from Amazon Web Services. The work plan is viewable here. The GitHub repository is here.
Novelty for novelty's sake (Score:5, Informative)
It's the circle of life in CS, and as time passes, more and more things are already invented, therefore there's no other option than re-doing them in the latest hipster-ish fad.
But some things just don't make sense to remake them. Su and sudo are foundational tools, where having them tested for decades is a feature.
Except it's not novelty nor well-tested (Score:4, Insightful)
I get that young developers want to earn reputation and prove their skills reinventing the wheel. It's the circle of life in CS, and as time passes, more and more things are already invented, therefore there's no other option than re-doing them in the latest hipster-ish fad. But some things just don't make sense to remake them. Su and sudo are foundational tools, where having them tested for decades is a feature.
Normally I agree with you, but in this case, these may have been "tested" for decades, but there are lots of vulnerabilities with them. Notice how they're only rewriting one vulnerable application and not the entire Linux kernel? It's a simple competition. If this group can write a more secure replacement that is just as nice and performant, it's a victory for all...if their rewrite sucks?...OK...back to the old version. Just because a tool is new doesn't necessarily mean it's better, like rust, but the reverse is true...just because a program is old, doesn't mean there's no room for improvement...AWS isn't throwing away money to be a hipster. They view it as a serious vulnerability.
Re: (Score:2)
Re: (Score:2)
"What vulnerabilities?"
Just to pick an example out of thin air, there was a nasty root vulnerability from a buffer overflow in sudo that got caught just a couple of years ago (CVE-2021-3156). I'm sure there are lots of others.
Memory (Score:2)
I see three or four memory/buffer related vulnerabilities over the last 20 years or so, looking at the CVE log. The vast majority have to do with PAM and weird combinations of third party management utilities related to file permissions, which rust isn't going to help.
Re: (Score:3)
More likely they're doing it to promote Rust, which they think is a good idea. They don't think there are vulnerabilities with this program. Rather, they think a super-high-profile project will bring credibility to Rust, which factions of their engineering team want to use.
"Rust? Is that a good idea?"
"Well, it's what su and sudo are written in!"
Re: Except it's not novelty nor well-tested (Score:2)
Iâ(TM)ve noticed how theyâ(TM)ve picked something that is simple to use and would be very difficult to make less nice and less performant. This wonâ(TM)t prove anything important.
Re: (Score:2)
Re: (Score:3)
Do you not see the engineering fallacy of your argument?
Especially, by your own argument, the majority of those vulnerabilities were NOT memory related. In fact, only just a third of those were memory related.
If you completely rewrite sudo, which had already, by your argument, removed 172 vulnerabilities, you may potentially reintroduce over 100 non-memory related vulnerabilities. As well as new memory vulnerabi
Re: (Score:3)
Sounds like the old one was getting too secure.
Define many (Score:2)
A simple search showed a vulnerability issue for sudo in 2021 and 2023.
And it exists since 1980 or so?
So, the question comes purely down to "why?'.
Well, it's actually not much of a question in today's fad obsessed culture.
Re: (Score:3)
A simple search showed a vulnerability issue for sudo in 2021 and 2023.
And it exists since 1980 or so?
So, the question comes purely down to "why?'.
Well, it's actually not much of a question in today's fad obsessed culture.
There was that time when the Debian package maintainer for sudo decided that the way it handled environment variables was 'unsafe' and modified it to his liking, putting it in as a 'security update' and broke rather a lot of peoples systems...
Re: (Score:2)
A Debian developer did the same thing for ssh host key generation, one upon a time.
These people may be rewriting it... (Score:3)
That doesn't mean all the distros are planning to adopt it.
Re: (Score:2)
Systemd.
Re: (Score:2)
Re: (Score:2)
How confident are Rust programmers? (Score:2)
As if memory related issues are the only issue.
But... (Score:2)
...will it still make you a sandwich?
How does that work (Score:3)
For architectures without the resources to build the rust toolchain?
Re: (Score:2)
Oh yeah I forgot, all software needs to work on all devices in all situations. All Linux and Unix systems are identical so anyone writing anything that doesn't work absolutely everywhere is just stupid. /S
Re: (Score:2)
Was that not the point of Linux and GNU? You have all the C code and tools to maintain and build your own system. Now that’s broken and you need something larger to cross compile with. Plenty of low power ARM devices can’t build rust natively.
Re: (Score:2)
Aren't you cross compiling from a more powerful platform for those targets anyway? And if rust doesn't support your low-powered architecture, can't you still use the C-based implementation of sudo? I don't thing it will go away any time soon.
Re: (Score:2)
Cross-compilers?
Re: (Score:2)
For architectures without the resources to build the rust toolchain?
The Rust toolchain uses the LLVM backend, which covers approximately all architectures in use today, and even many that are not. What is an architecture you'd like to use for which there is no LLVM support? Granted that it might take some work to get Rust self-hosting on obscure architectures, but cross-compilation to basically anything is pretty easy.
God mode (Score:3, Funny)
What if.....
Re: (Score:2)
So close... (Score:2)
...to being able to make a Genesis joke. Damn.
Re:So close... (Score:5, Funny)
...to being able to make a Genesis joke. Damn.
You're thinking of a Phil Collins single, but I saw what you did, I saw it with my own two eyes.
Re: (Score:2)
"I Wish It Would Rain"?
Duplicate effort? (Score:3)
and 'doas' ? (Score:2)
I recently found I had to make a tech debt payment when Alpine replaced 'sudo' with 'doas'. Do I feel assured that it's better? Not really.
X, but written in Rust (Score:2)
Re: (Score:2)
On the other hand, rewriting X in Rust might be worthy of an article.
"With the financial backing of Amazon Web Service" (Score:2)
Because quality open source software needs large budgets, amiright?
Rust isn't more safe (Score:2)
Rust is just another language/framework with its own problems and bugs. Sudo and su are so old and should have had most memory issues resolved. I think it's more with them wanting to do something and getting paid for it.
Re: (Score:2)
Time for a Rustless distro (Score:2)
I'm rewriting sudo in Python (Score:2)
because Python is superior when it comes to handling memory.
I'm only struggling to get the indents right.
I'd wish one could use tabs to nicely line-up everything but the evil Dutch Dictator decided that tabs were evil on his 40-column CRT.
Rust enthusiasts fork sudo/su, film at 11 (Score:2)
Why rewrite instead of deprecate (Score:2)
At least, sudo. Su still has uses, but sudo is outright harmful. That is, on multi-user machines, what is was meant for. On single user systems, where its seems nowadays seems all but inevitable, it does not even have a proper function.
https://michaeleriksson.wordpr... [wordpress.com]
Question from a non-dev linux user (Score:2)
Re:And for new bugs (Score:5, Informative)
mature and well debugged software
Yeah. About that [theregister.com] ...
Re: (Score:3, Insightful)
One of the few memory safety issues with sudo. There is a ton of problems it had which are _not_ memory safety and many of them can easily be re-introduced in a reimplementation. Ah, and sudo is generally a pretty broken idea as it is exceptionally hard to secure and that has absolutely nothing to do with memory safety.
Re:And for new bugs (Score:5, Interesting)
many of them can easily be re-introduced in a reimplementation
Maybe, maybe not. The thing is, sudo and su aren't some rock solid bug free piece of code which you predicated your original argument upon. You are popping up a "maybe this might happen" and supporting it with "because sudo is mature and well debugged software". Which I wouldn't call it such, seeing how it was only in 2019 did the underflow bug [redhat.com] get fixed in modern distributions, something that Rust just doesn't allow to happen.
So I get what you are trying to get at here. But sudo and su are some of the programs that I would say you toss massive grains of salt on opinions that go along the lines of your take on it.
Ah, and sudo is generally a pretty broken idea as it is exceptionally hard to secure and that has absolutely nothing to do with memory safety
Then what are you even here complaining about? Are you just wanting to yell at a cloud [knowyourmeme.com]? Yes, sudo is hard to secure and has a ton of edge cases. Congrats on stating the obvious. And as they've indicated on the project's page their phase two validation is to test all of the CVEs against their implementation.
Good gosh, sometimes this site goes hard for the "back in my day" mentality. This is the same kind of thinking that keeps COBOL around.
Re:And for new bugs (Score:4, Funny)
Re: (Score:2)
Jfc, everyone knows Fortran 77 is a way better systems language than cobol.
Re:And for new bugs (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
Besides 90% of COBOL developers monitoring their 401(k) balance every morning to see if next month is when they can retire, nothing!
Re:And for new bugs (Score:5, Insightful)
But also, Rust is not some magical fairy dust that makes all the problems go away. Yes, Rust may improve things, but it might not.
All this hype should be a warning sign. There's a real danger is assuming "impossible to have bugs with the new magic fad of the day!" and I have seen people fall into this trap - remember, Java was supposed to be safe because it ran in a perfect sandbox and thus safe to run random code from the net in your browser. Experience tells me to beware of hype.
Re:And for new bugs (Score:4, Insightful)
Yes, Rust may improve things, but it might not.
Yes, and the benefit of projects like this is it gives a chance to see how Rust performs in a real-world security-critical scenario. If it lives up to the hype, then great! If not, we can analyze where things went wrong, and apply those lessons learned towards future versions of Rust (or whatever comes along to replace it later).
Re:And for new bugs (Score:5, Insightful)
Yes, and the benefit of projects like this is it gives a chance to see how Rust performs in a real-world security-critical scenario.
It's not the language. We know that Rust will prevent memory errors (unless the programmer is REALLY bad).
It's about the programmers. We've seen that most security bugs in SUDO are not from memory errors, they are from other things. So whether the project succeeds or fails, it shouldn't be taken as proof that Rust is "bad." It's a perfectly acceptable language. It's also a language where you can write plenty of security bugs.
Re: (Score:3)
It's not the language. We know that Rust will prevent memory errors (unless the programmer is REALLY bad).
So will C++, and it wouldn't be a complete rewrite from the ground up.
Re: (Score:2)
Re: (Score:2)
That's the problem with C++ - it's layer upon layer of templates trying to paper over the cracks in the language and since the language allows raw pointers you'll never be safe.
Re: (Score:2)
Indeed. C++ doesn't prevent memory errors in the same way as rust, but it sure helps.
The OSS community has had virulently strong anti C++ opinions for a long time. I love me some C++, but we can't go back in time on this one. Either way, a language that allows automating away the tedious and error prone parts of programming is going to be an improvement.
It is possible to write secure, high quality C. OpenBSD manage with strict rules, and repeated audits. The penalty is the huge amount of time taken, and eve
Re: (Score:2)
Rust wouldn't be necessary if we lived in a world where everyone was Super-Programmer, writing 100% correct and safe C/C++. But we're not and even the most experienced programmers introduce bugs that make it into production code. And many people are far less experienced than that. Since many of these bugs (NPEs, data races, buffer overflows etc.) are due to the language & compiler, what exactly is the problem with choosing another language that doesn't have these issues but produces equivalent & per
Re: (Score:2)
Except finding out if Rust is better here might take decades - that's how long it took for some of these CVEs to appear.
Re:And for new bugs (Score:5, Insightful)
There's a real danger is assuming "impossible to have bugs with the new magic fad of the day!" and I have seen people fall into this trap
I've seen it too. I've seen it for venerable things like C and C++. I distinctly remember the push and push back in the middle 90s of OOP is "awesome" / "hype". Remember when RAD programming was all the rage?
Experience tells me to beware of hype
And more experience tells you that this is just another in a long line of things we've all already seen. RAD didn't explode the way some thought it would, but it did serve as a template for what came after. Java had extremely lofty goals that were just that. However, it morphed into something that is used in a lot of business critical use cases. C++ wasn't the awesome everyone thought it was going to be, but the c++11 has shown that it is willing to move into something even greater than c++98 was.
Everything is a moving object in an industry that is all about constant change. "Beware of the hype" is the number one thing I hear when modernization efforts are first purposed. Literally, was in a group meeting the other week about an old group of modules that were RPGIII (RPG/400) modules that have been in use since the early 80s. Team "pro" was pitching gaining the ILE environment for these modules. Team "con" was literally pitching, "don't buy the hype" the ILE won't give us major gains and we'll have all these issues. Hadn't even gotten into a technical discussion and already the "don't buy the hype" argument was being used for why the company should continue to keep those old ass modules limping along.
So I'll tell you that, yeah you should take the hype with a grain of salt. But we've already got people here on Slashdot saying "DO NOT EVEN TRY IT, YOU WILL BREAK EVERYTHING!! YOU DON'T KNOW WHAT YOU ARE DOING!!" So yeah, you can jerk hard on the hype, but you can just as easily jerk hard on being dismissive. That's what I'm getting at.
Re:And for new bugs (Score:4, Insightful)
but it did serve as a template for what came after. Java had extremely lofty goals that were just that.
Weirdly the goal of cross-platform compatibility was largely met by reducing the number of platforms available.
Re:And for new bugs (Score:4, Insightful)
So yeah, you can jerk hard on the hype, but you can just as easily jerk hard on being dismissive.
getting back on the topic, the dilemma of when to rewrite old components is a common one in the field and there is never a straight and correct answer, it's always a risk and a tradeoff highly dependent on the particularities of the case and situation. in the case of sudo i don't know the particulars well enough to have an informed opinion, but i see lots of opinions in the thread that despite appearing very confidently for or against don't really exhibit detailed enough insight into this specific instance to seem serious.
if i had to follow my gut i'd say the memory safety of rust, while interesting, isn't probably a good enough tradeoff in this case. then again that's just gut instinct, i haven't even looked at the source code nor do i know the detailed maintenance history and current status of this component, this is just a generic opinion based on the criticality of the component and the purported possible benefits in this case.
then again there's no harm in trying as long as proper testing and process is guaranteed before replacement. that's where politics and personal opinions would be best to kept away from influencing decisions.
Re: (Score:2)
already the "don't buy the hype" argument was being used for why the company should continue to keep those old ass modules limping along.
Someone might be showing their bias here. Just because something is old does not imply a new version will necessarily be better.
Re: (Score:2)
C and Rust are low level programming languages that are parsed & compiled into an intermediate instruction set by a front end compiler, which is then optimized and turned into target machine code by a backend. Performance of Rust is about equivalent to C (or C++). The reason Rust has gotten a lot of traction is the language and compiler prevent a lot of issues that C/C++ would allow through without complaining about.
Rust actually uses LLVM as its backend which is the same as the Clang C compiler. So Rus
Re: (Score:2)
In C, you have to manage the application memory manually. In other words, you have to ask for (allocate) memory from the OS, return (free) it, and make sure it has a "properly set" value (initialized, updated) when you use it, and that you aren't using the wrong location (address).
In Rust, the memory is automatically managed. So allocation, freeing, initialization, and addresses are performed by the compiler before and after you access a value. You are still responsible for proper updates.
Other than that
Re:And for new bugs (Score:5, Insightful)
No one has ever claimed rust make all problems go away other than people who are against rust making up some false narrative. Rust addresses some very specific problems. Nothing more. It doesn't address all bugs, certainly it will have edge cases, yet it is completely undeniable that it is an improvement.
I wear a seatbelt while driving. It doesn't make me immortal, but it addresses quite a few situations which would otherwise cause my demise.
Re: (Score:2)
But current sudo/su is already pretty solid, and 'we' know the pitfalls with C and it's memory problems which should already be caught by a decent compiler which has checks for stuff like that.
Re: (Score:2)
No. Compilers are getting to be better static analyzers but they are a very long way from perfect. Rust is constructed specifically to allow analysis of memory safety errors, so it will be more complete.
Re: (Score:2)
Neither was Python. Or Perl. Or C++. Or any of the powerful, expensive, and unstable commercial privilege management systems, designed from PowerPoint presentations by middle management. Forgive my cynicism, if you will, I just had to clean up a literally insane BeyondTrust environment where its champions refused to acknowledge that they had designed a very expensive single point of failure.
Re: (Score:2)
And nobody has ever said it was magical fairy dust that makes all problems go away. It's quite possible to write application logic which does the wrong thing in Rust as it is in any language.
However, Rust *does* protect you from data races, buffer over/underflows, memory leaks, null pointer exceptions, double free & heap corruption. It does so without impacting performance, producing code which runs as efficiently as properly written C or C++. It demonstrably produces safer code with less bugs.
And no Ru
Re: (Score:2)
Most of those protections do impact performance. That's why there are options to turn off checking.
Re: (Score:2)
"Safe" was said often by early Java promoters and fans. Safe here did not mean "zero bugs", it meant that if there is a bug it can't escape the sandbox. But the sandbox itself had bugs and thus exploits were possible.
Re: And for new bugs (Score:2)
Running regression tests from another implementation only proves you havenâ(TM)t made the same mistakes. It doesnâ(TM)t prove that you havenâ(TM)t made new ones. All new code has bugs.
Re: (Score:2)
You are popping up a "maybe this might happen" and supporting it with "because sudo is mature and well debugged software". Which I wouldn't call it such, seeing how it was only in 2019 did the underflow bug [redhat.com] get fixed in modern distributions, something that Rust just doesn't allow to happen.
I'm a big Rust fan and I think this rewrite is an excellent idea, unfortunately, your statement isn't correct.
In debug mode, Rust adds underflow/overflow checks and will panic if those are detected. But, in release mode, Rust doesn't check for underflow/overflow and will silently wrap around.
This is done for performance reasons. Rust doesn't always protect against logical bugs, like this, although it usually helps. The main focus, of course, is on eliminating memory errors.
Re: (Score:2)
Then what are you even here complaining about? Are you just wanting to yell at a cloud? Yes, sudo is hard to secure and has a ton of edge cases. Congrats on stating the obvious. And as they've indicated on the project's page their phase two validation is to test all of the CVEs against their implementation.
Good gosh, sometimes this site goes hard for the "back in my day" mentality. This is the same kind of thinking that keeps COBOL around.
The issue with rewriting everything just to address a tiny subset of problems is the devil you don't know. You have no way of reasoning about whether the new effort will ultimately be an improvement over the old or simply introduce an entirely new set of problems.
I would support a sudo re-implementation using formal methods or similar engineering process that provided high assurance of correctness. Simply picking a different language for all anyone knows may well result in worse outcomes.
Re: (Score:2)
This is the same kind of thinking that keeps COBOL around.
COBOL is a great language in it's domain.
Re: (Score:2)
Don't they have a test suite for sudo? It should be possible to test any implementation automatically, to check for regressions.
Re: (Score:2)
Yeah, that's why you perform regression testing.
Re:And for new bugs (Score:4, Funny)
I avoid that by logging in as root from the console!
Re: (Score:2)
Re: And for new bugs (Score:2)
Re: (Score:2)
Re: (Score:2)
I’m appalled that young people don’t use xyzzy any more.
Re: (Score:2)
Would that it were the most appalling thing about young people. Look what they've done to my boy^Wlawn...
Re: (Score:2)
Nope, it's blank. Nobody ever suspects a blank root password.
Re: (Score:2)
That's fine. But you still have to delete the su and sudo binaries to keep unauthorized users from exploiting them.
Re: (Score:2)
Re: (Score:3, Insightful)
What's your point? In its entire lifetime there are less than 20 CVEs relating to sudo (including a couple of issues around escaping characters to stdout and parsing errors introduced by Fedora) and over 6,000 CVEs related to Cisco, yet plenty of Fortune 500 companies are still using Cisco hardware and software.
If anything a rewrite in language-flavor-of-the-month is going to create a bunch of new CVEs.
Re: (Score:2)
Are you under some impression that writing it in Rust will avoid the conflicting foibles of 20 or 30 years of hands-on demands from people like Lennart Pottering, each of whom wants to architect their own grand vision?
Re:And for new bugs (Score:5, Informative)
However, a look at vulnerabilities for the last 20 years [cvedetails.com] shows that most of them aren't memory related, so whoever re-implements this better make sure they understand how environment variables work, how forking works, and parsing command lines works, Linux PAM modules work, along with all the other edge cases, otherwise they are going to reinvent all the bugs over again.
Re:And for new bugs (Score:5, Insightful)
That is just my point. Memory safety issues usually get found in the first decade or so. Memory safety issues can also be found using tools like Fortify. What remains are design problems and insight problems and these are just as easy to have in Rust as in C.
Re: (Score:2)
Re: (Score:2)
Indeed. Ignorance does not breed excellence but it can cause bad disconnect.
Re: (Score:2)
Re:And for new bugs (Score:5, Insightful)
I doubt it. Subtle security bugs can often not reasonably be covered by test-code. For example a subtle race can be far too unlikely on one machine and still require a few days on another one to be found. It is a valid security problem nonetheless because attackers may go after thousands of different systems and a few days attack time are not a real obstacle. Also, there are bugs that are suspected to be exploitable, but no actual exploit code (= test code) is available. These still need to be found and fixed.
Testing for security is somewhere between hard and impossible, because you must find _unwanted_ functionality that may not always even be present and may behave in countless different ways. Testing for functionality is easy, because you just test whether the wanted functionality is there.
So no. Existing test code will not even cover all known or suspected vulnerabilities.
Re: (Score:2)
What, you're not looking forward to the next crop of sudo 2.x security bugs? Where's your sense of adventure?
Re: (Score:2)
Yeah, because unidentified exploitable bugs have never laid dormant in open source software in use by millions of people before *cough*openssl heartbleed*hack*
Re:Who said replace? (Score:4, Insightful)
Just because Poettering wrote systemd and pulseaudio doesn’t mean you have to use them. Oh wait..,
Re: (Score:2)
Just because Poettering wrote systemd and pulseaudio doesn’t mean you have to use them. Oh wait..,
Slackware over here. What is this systemd of which you speak?
Re: (Score:2)
Just because Poettering wrote systemd and pulseaudio doesnâ(TM)t mean you have to use them. Oh wait..,
sysvinit and pipewire here on my Devuan system. pulseaudio's day is done, now if only the distributions would get the memo.