9 ms·

Bringing Memory Safety to sudo and su

94 points by mritzmann 3y ago

PeterWhittaker 3y ago
Good plan. Reimplementing in Rust using a carefully planned milestone-based approach should result in feature parity with fewer security vulnerabilities.
- temporarara 3y ago
  There is zero guarantee about that. The result could have fewer vulnerabilities, but it's not an easy thing to do. I'd say there definitely are some vulnerabilities left in sudo code, but over the years all the obvious bugs have already been eliminated and rewriting it in a new language can reintroduce a lot of those. Now, if the people doing this are competent and have time and money in their hands, rust enables doing some things better and basically lets you forget about basic and advanced memory bugs, so the final product may well be a good (better) one. But just using another language to reimplement something in order to make it "safer" in some abstract manner does not guarantee anything. Good coding practices combined with "elementary" and highly-portable language like C can also result in victory that can't really be challenged. We'll see.
vermaden 3y ago
Why not just use doas(1) instead? doas(1) - doas(1) - portable version has about 500 lines of code - doas(1) man pages - 157 lines long - doas(1) had 2 CVEs sudo(8) - sudo(8) - about 120,000 lines of code (100x more) - sudo(8) man pages - 10 000 lines long - sudo(8) had 140 CVEs The CVEs comparison is from 'all time' and as sudo(8) has longer history then doas(1) - it will (at least statistically) have more of these ... I expect doas(1) to have about 5-10 CVEs when they would have the same life span. Regards, vermaden
johnisgood 3y ago
Rewrite it in an actually "safe" language, like Ada.
- pdimitar 3y ago
  I don't speak for this project but when I tried Ada I was disappointed with the library ecosystem. Many things are missing. Granted I'm not a systems programmer. Just giving you one random programmer's reason to skip it.
  - johnisgood 3y ago
    Yes, the ecosystem definitely needs more attraction. "People do not use it because the ecosystem sucks, and the ecosystem sucks because people do not use it." That said, it is more than enough for many use-cases that are related to critical software. Either way, what you should focus on is the cyber-security aspect of Ada/SPARK. It is actually the language and programming environment for secure/crticial software.
    - pdimitar 3y ago
      > That said, it is more than enough for many use-cases that are related to critical software. Says you. It wasn't enough for the work I wanted to do for a fintech company. ¯\_(ツ)_/¯
      - johnisgood 3y ago
        What were you missing?
jmclnx 3y ago
Will this replace the current sudo ?
- dochtman 3y ago
  It’s a separate project. We’ll see if/when these new Rust-based versions become good enough for people to adopt as their daily driver sudo/su.
  - therein 3y ago
    I am sure they'll use the same name, though. Hard to come up with a name for this one. rsu, rsudo surs, sudors (and then /etc/sudorsers as the cherry on top)
    - Fnoord 3y ago
      endorse surrogate I don't know. But if its a drop-in replacement, which aims compatibility, then the same name seems OK. And for most use-cases, this will be a drop-in replacement. Except for obscure configs. But I think that's OK. If your goal is world domination, you aim for the low hanging fruit first.
- zimpenfish 3y ago
  There's always doas[1] if you want a simpler, safer version. [1] https://en.wikipedia.org/wiki/Doas https://en.wikipedia.org/wiki/Doas
  - Gigachad 3y ago
    Still written in an insecure language.
    - johnisgood 3y ago
      Lord... name checks out though.
    - jmclnx 3y ago
sc68cal 3y ago
My concern is that while re-implementing sudo in rust would solve bugs due to memory safety and off by one errors, it is a complex piece of software where logic errors can create serious security issues. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-22809 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2280...
- throwawaaarrgh 3y ago
  [flagged]
  - Rusky 3y ago
    This isn't how people seriously approach memory safety. Memory safety is a critical starting point, because without it you can no longer trust the logic you wrote in your program to behave in any particular bounded way. Memory safety bugs undermine everything else.
  - woodruffw 3y ago
    “Free-after-use” is not a vulnerability class; it’s “use-after-free.” And Rust’s borrow checker provides temporal memory safety; you could even say that it primarily exists to prevent temporal vulnerability classes like UAFs.
  - jcranmer 3y ago
    Rust protects against most memory safety vulnerabilities: use-after-free, out-of-bounds accesses, returning dangling pointers. Probably the memory safety vulnerability it's the least protective against is using uninitialized memory. And recall that memory safety vulnerabilities are the vast majority of software vulnerabilities--somewhere in the 70+% range. But Rust doesn't only touch memory safety, it also has some measure of protection for other vulnerabilities. It's somewhat stricter on integer overflow vulnerabilities. Newtypes can be used to provide protection against validation vulnerabilities (e.g., SQL injection). Send and Sync traits can provide some measure of protection against data races: it takes a little bit of effort to use an object on a different thread if it's not able to be used from multiple threads. You don't hear as much about these protection efforts because, quite frankly, memory safety is so important that it alone is sufficient to drive many decisions.
nhellman 3y ago
There is also 'doas' from the OpenBSD project. It's a replacement for 'sudo' with fewer features and a smaller codebase, with the aim of a smaller attack surface. https://en.m.wikipedia.org/wiki/Doas https://en.m.wikipedia.org/wiki/Doas
- smabie 3y ago
  Though written in C for no apparent reason. It's ironic to me how security focused OpenBSD is while at the same time looking down on any other language besides C.
  - yjftsjthsd-h 3y ago
    > for no apparent reason Here's the list of hardware platforms that OpenBSD supports: https://www.openbsd.org/plat.html https://www.openbsd.org/plat.html Note that when they say support, they mean that it's fully supported and actually works well, including that OpenBSD is fully self-hosting on that platform (read: "oops, the compiler OOMs on 32-bit" is a no-go). Now, here's the list of targets that rust supports: https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html Notice that all the OpenBSD targets are tier 3, and it's a strict subset of OpenBSD's platoforms. Even if we ignore everything else - a questionable choice - rust is unsuitable for writing core parts of OpenBSD because it can't actually build for all the systems that OpenBSD supports.
    - jcranmer 3y ago
      The point GP was (probably) trying to make is that OpenBSD's vision of security is at odds with its insistence on C, a notoriously unsafe and insecure language. There's no reason that the replacement language has to be Rust; it could be Nim or Zig or C# or Java or Vala or OpenBSD Custom Memory-Safe Language. What it takes for OpenBSD to choose to support whichever language it wants to is primarily a commitment to actually spend its resources to support said language. That the OpenBSD targets for Rust are tier 3 is a sign of its unwillingness to consider moving away from C: what it takes to move from tier 3 to tier 2 is a set of maintainers who have a commitment to be responsive to patches, and an automated CI solution. (Also note that OpenBSD is the largest Unix "stuck" in tier 3 for Rust. Solaris/Illumos, FreeBSD, and NetBSD all manage to have tier 2 builders. Even Fuchsia and Redox have tier 2 support!)
Dolamifa 3y ago
Can't be more excited for that!
hannob 3y ago
This sounds good, however, I hope they don't try to replicate all of sudo. sudo fails a basic security principle on Unix systems, and that is that suid binaries should be simple. Their developers have a tendency to add all kinds of stuff that barely anyone ever uses, but that bloats its size.
- steveklabnik 3y ago
  If you read the README https://github.com/memorysafety/sudo-rs https://github.com/memorysafety/sudo-rs > Our current target is to build a drop-in replacement for most basic use cases of sudo. ... > Some parts of the original sudo are explicitly not in scope. Sudo has a large and rich history and some of the features available in the original sudo implementation are largely unused or only available for legacy platforms. In order to determine which features make it we both consider whether the feature is relevant for modern systems, and whether it will receive at very least decent usage. Finally of course a feature should not compromise the safety of the whole program. So seems like they're on the same wavelength as you are.
- rnijveld 3y ago
  Definitely one of the things that is on our radar! Lots of features in sudo are just basically legacy features, remnants from the 90s or 00s that are no longer necessary in a modern setup, but nevertheless exist because in past times they used to be the default or only option. We are particularly aware of how much power a suid binary has, so we do try to be cautious!
musicale 3y ago
A few years back I was annoyed that sudo would consistently crash with a memory error.
rurban 3y ago
Memory safety would be good, but why then use a memory unsafe language?
- PeterWhittaker 3y ago
  Correct me if I am wrong, but isn’t Rust unsafe only when explicitly using unsafe? Provided this project does not do that, it would be memory safe, no?
  - rurban 3y ago
    Look up their bugreports for stack overflow, besides unsafe blocks everywhere.
  - johnisgood 3y ago
    Anything more than hello world is full of unsafe blocks. You need it. In any case, Ada/SPARK would be the most ideal choice for a "safe" language, not Rust. So tiring.
    - pdimitar 3y ago
      Indeed, this hate is very tiring to find on such threads. Consider not caring. I'll try to do the same.
      - johnisgood 3y ago
        Is my statement considered hate? Is it not the truth, though? Any projects I pick, including Rust's standard library, there are unsafe blocks everywhere, and as a Rust developer has said, those blocks do affect code outside of it.
        pdimitar 3y ago
        Not this one in particular. It's your tone in this entire thread in general.
notorandit 3y ago
> But because it's written in C, sudo has experienced many vulnerabilities related to memory safety issues. Or because it's not been developed with enough care? I for one think that there is no unsafe language, only careless programmers.
- actionfromafar 3y ago
  Right! Like with airplanes, there are no unsafe airplanes, only careless pilots.
  - stephc_int13 3y ago
    This analogy is completely wrong. The programmer would be the aero engineer, not the pilot. The pilot would be the sysadmin, maybe?
- justin_oaks 3y ago
  > there is no unsafe language Perhaps you didn't intend it this way, but that implies that there is no difference in safety between languages. This is a patently absurd idea. C is clearly less safe than many languages that don't allow unsafe memory practices.
- rnijveld 3y ago
  I think your expectations are too high. During our initial exploration we actually managed to talk to Todd Miller, the maintainer of sudo. In our (brief) interactions with him he did not sound cavalier like this at all. Instead I think that a lot of the issues with sudo are more about it being a thirty+ year old program and codebase, and sometimes features turn into bugs and security issues all on their own in such time periods. But then again, C just cannot offer the kinds of protections that Rust can, and mistakes will be made eventually by every human, better to have some protection from your mistakes than none at all.
stephc_int13 3y ago
This so-called memory safety is looking like a buzzword engineered to be extremely appealing to a type of mildly technical but mostly illiterate about computer security kind of people. This has been said before, this has been tried before, OOP was also seen as silver bullet at some point, like several others. Computer security is a deeply complex and dirty field, switching programming language won’t help much if programmers are expecting the work to be done for them by the compiler. If you want robust code : hire experts in the field and pay the price. Rewriting sudo is almost certainly going to be painful and to increase the vulnerabilities potential.
- cedilla 3y ago
  Alright, I'll take the obvious bait. The experts in the field are right over there, getting paid to rewrite it in rust.
  - stephc_int13 3y ago
    Experts with Rust? Experts about sudo implementation requirements? Or computer security experts? Because you’ll probably need all of that.
- rnijveld 3y ago
  I’m on the team that is creating sudo-rs. I agree that just assuming that memory safety will get rid of all the bugs is just plain wrong, it will prevent some particular classes of bugs, but that is all it does. But we do think that sudo in particular suffers from being a really old codebase, and that especially on that point we can make progress. Sudo has lots of features no longer relevant. It has a plugin interface, but that interface uses almost exclusively strings in `key=value` format, and the plugin boundaries aren’t perfect either. It has behaviors that probably almost nobody relies on and yet add complexity and increase the attack surface. If we wanted to do something about that it would mean rewriting large parts of sudo. So if we’re re-implementing sudo anyway, why not start at the basics and build it a little better. Aside from the memory safety I think that is one of our main goals: make a simpler sudo that still has lots of the expressiveness. I hope you agree that cleaning up sudo is a good thing, and if we are doing that, we might as well take some memory safety along for the ride.
jacooper 3y ago
Another tool getting reimplemented in Rust under a weak license. Do people want to ruin the Linux Eco system or what? It only takes on distro to close its modified source(backports, bugfixes etc) for the entire Eco system to start to crack.
- johnisgood 3y ago
  Don't worry, there will be at least one distro using C and exclude Rust completely, or at least I'd hope so. Too bad the Linux kernel has Rust in it.
  - jacooper 3y ago
    The problem isn't the language, its the license.
pyuser583 3y ago
This just isn’t necessary. There’s excellent C tooling that identifies memory safety issues. It seems any program that meets the four criteria would better served by rigorous analysis of the existing code.
- johnisgood 3y ago
  Indeed. This Why Not Rewrite It In Rust (RIIR) is absurd. I question their competency with regarding to C. I suppose they are just regurgitating each other's sentences without actually looking much into C and related tooling. That, or Ada/SPARK.
  - pdimitar 3y ago
    Ada/SPARK has fallen behind on the rich library ecosystem. I've vetted it once about 7 months ago. I don't dig the syntax but that's 98% irrelevant; professionals shouldn't care about it. However, the lack of stuff I take for granted when working with several other languages, Rust included, drove me away. Nobody is paying me to enrich an ecosystem (even though I'd gladly take the opportunity to do so for a few languages I hold dear). --- On the regurgitating part, I feel obliged to point out that you're doing exactly the same as those you accuse of doing it. Rust is making strides and extremely serious engineers and decision makers are using and recommending it: part of the Linux kernel community, France's intelligence agency, Google's Android and Fuchsia projects, a lot of Fintech companies, and many others. You and others being eternally skeptical and feeling the need to insult adopters sounds like you just want people off your lawn without an objective analysis. And without taking feedback from companies who successfully adopted Rust and wrote good blog posts with both pros and cons. I'd question your competence if you think you know better than Google, Linux kernel devs and GCHQ. It's your right to echo-chamber yourself, the world keeps moving though.
    - johnisgood 3y ago
      According to your other answers, you have already concluded that opposing RIIR is due to a hatred for Rust. I doubt there will be any convincing of you, I did attempt it when I replied to one of your comments. > I'd question your competence if you think you know better than Google, Linux kernel devs and GCHQ. Could I not say the same though? Ada is used in avionics, air traffic control, railways, banking, military and space technology, i.e. critical software. Are they wrong but they do not know it yet? Should they switch to Rust? Either way, I find your conclusions questionable.

94 points by mritzmann 3y ago

Good plan. Reimplementing in Rust using a carefully planned milestone-based approach should result in feature parity with fewer security vulnerabilities.

temporarara 3y ago
There is zero guarantee about that. The result could have fewer vulnerabilities, but it's not an easy thing to do. I'd say there definitely are some vulnerabilities left in sudo code, but over the years all the obvious bugs have already been eliminated and rewriting it in a new language can reintroduce a lot of those. Now, if the people doing this are competent and have time and money in their hands, rust enables doing some things better and basically lets you forget about basic and advanced memory bugs, so the final product may well be a good (better) one. But just using another language to reimplement something in order to make it "safer" in some abstract manner does not guarantee anything. Good coding practices combined with "elementary" and highly-portable language like C can also result in victory that can't really be challenged. We'll see.

vermaden 3y ago

Why not just use doas(1) instead? doas(1) - doas(1) - portable version has about 500 lines of code - doas(1) man pages - 157 lines long - doas(1) had 2 CVEs sudo(8) - sudo(8) - about 120,000 lines of code (100x more) - sudo(8) man pages - 10 000 lines long - sudo(8) had 140 CVEs The CVEs comparison is from 'all time' and as sudo(8) has longer history then doas(1) - it will (at least statistically) have more of these ... I expect doas(1) to have about 5-10 CVEs when they would have the same life span. Regards, vermaden

johnisgood 3y ago

Rewrite it in an actually "safe" language, like Ada.

pdimitar 3y ago
I don't speak for this project but when I tried Ada I was disappointed with the library ecosystem. Many things are missing. Granted I'm not a systems programmer. Just giving you one random programmer's reason to skip it.
- johnisgood 3y ago
  Yes, the ecosystem definitely needs more attraction. "People do not use it because the ecosystem sucks, and the ecosystem sucks because people do not use it." That said, it is more than enough for many use-cases that are related to critical software. Either way, what you should focus on is the cyber-security aspect of Ada/SPARK. It is actually the language and programming environment for secure/crticial software.
  - pdimitar 3y ago
    > That said, it is more than enough for many use-cases that are related to critical software. Says you. It wasn't enough for the work I wanted to do for a fintech company. ¯\_(ツ)_/¯
    - johnisgood 3y ago
      What were you missing?

jmclnx 3y ago

Will this replace the current sudo ?

dochtman 3y ago
It’s a separate project. We’ll see if/when these new Rust-based versions become good enough for people to adopt as their daily driver sudo/su.
- therein 3y ago
  I am sure they'll use the same name, though. Hard to come up with a name for this one. rsu, rsudo surs, sudors (and then /etc/sudorsers as the cherry on top)
  - Fnoord 3y ago
    endorse surrogate I don't know. But if its a drop-in replacement, which aims compatibility, then the same name seems OK. And for most use-cases, this will be a drop-in replacement. Except for obscure configs. But I think that's OK. If your goal is world domination, you aim for the low hanging fruit first.
zimpenfish 3y ago
There's always doas[1] if you want a simpler, safer version. [1] https://en.wikipedia.org/wiki/Doas https://en.wikipedia.org/wiki/Doas
- Gigachad 3y ago
  Still written in an insecure language.
  - johnisgood 3y ago
    Lord... name checks out though.
  - jmclnx 3y ago

sc68cal 3y ago

My concern is that while re-implementing sudo in rust would solve bugs due to memory safety and off by one errors, it is a complex piece of software where logic errors can create serious security issues. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-22809 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2280...

throwawaaarrgh 3y ago
[flagged]
- Rusky 3y ago
  This isn't how people seriously approach memory safety. Memory safety is a critical starting point, because without it you can no longer trust the logic you wrote in your program to behave in any particular bounded way. Memory safety bugs undermine everything else.
- woodruffw 3y ago
  “Free-after-use” is not a vulnerability class; it’s “use-after-free.” And Rust’s borrow checker provides temporal memory safety; you could even say that it primarily exists to prevent temporal vulnerability classes like UAFs.
- jcranmer 3y ago
  Rust protects against most memory safety vulnerabilities: use-after-free, out-of-bounds accesses, returning dangling pointers. Probably the memory safety vulnerability it's the least protective against is using uninitialized memory. And recall that memory safety vulnerabilities are the vast majority of software vulnerabilities--somewhere in the 70+% range. But Rust doesn't only touch memory safety, it also has some measure of protection for other vulnerabilities. It's somewhat stricter on integer overflow vulnerabilities. Newtypes can be used to provide protection against validation vulnerabilities (e.g., SQL injection). Send and Sync traits can provide some measure of protection against data races: it takes a little bit of effort to use an object on a different thread if it's not able to be used from multiple threads. You don't hear as much about these protection efforts because, quite frankly, memory safety is so important that it alone is sufficient to drive many decisions.

nhellman 3y ago

There is also 'doas' from the OpenBSD project. It's a replacement for 'sudo' with fewer features and a smaller codebase, with the aim of a smaller attack surface. https://en.m.wikipedia.org/wiki/Doas https://en.m.wikipedia.org/wiki/Doas

smabie 3y ago
Though written in C for no apparent reason. It's ironic to me how security focused OpenBSD is while at the same time looking down on any other language besides C.
- yjftsjthsd-h 3y ago
  > for no apparent reason Here's the list of hardware platforms that OpenBSD supports: https://www.openbsd.org/plat.html https://www.openbsd.org/plat.html Note that when they say support, they mean that it's fully supported and actually works well, including that OpenBSD is fully self-hosting on that platform (read: "oops, the compiler OOMs on 32-bit" is a no-go). Now, here's the list of targets that rust supports: https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html Notice that all the OpenBSD targets are tier 3, and it's a strict subset of OpenBSD's platoforms. Even if we ignore everything else - a questionable choice - rust is unsuitable for writing core parts of OpenBSD because it can't actually build for all the systems that OpenBSD supports.
  - jcranmer 3y ago
    The point GP was (probably) trying to make is that OpenBSD's vision of security is at odds with its insistence on C, a notoriously unsafe and insecure language. There's no reason that the replacement language has to be Rust; it could be Nim or Zig or C# or Java or Vala or OpenBSD Custom Memory-Safe Language. What it takes for OpenBSD to choose to support whichever language it wants to is primarily a commitment to actually spend its resources to support said language. That the OpenBSD targets for Rust are tier 3 is a sign of its unwillingness to consider moving away from C: what it takes to move from tier 3 to tier 2 is a set of maintainers who have a commitment to be responsive to patches, and an automated CI solution. (Also note that OpenBSD is the largest Unix "stuck" in tier 3 for Rust. Solaris/Illumos, FreeBSD, and NetBSD all manage to have tier 2 builders. Even Fuchsia and Redox have tier 2 support!)

Dolamifa 3y ago

Can't be more excited for that!

hannob 3y ago

This sounds good, however, I hope they don't try to replicate all of sudo. sudo fails a basic security principle on Unix systems, and that is that suid binaries should be simple. Their developers have a tendency to add all kinds of stuff that barely anyone ever uses, but that bloats its size.

steveklabnik 3y ago
If you read the README https://github.com/memorysafety/sudo-rs https://github.com/memorysafety/sudo-rs > Our current target is to build a drop-in replacement for most basic use cases of sudo. ... > Some parts of the original sudo are explicitly not in scope. Sudo has a large and rich history and some of the features available in the original sudo implementation are largely unused or only available for legacy platforms. In order to determine which features make it we both consider whether the feature is relevant for modern systems, and whether it will receive at very least decent usage. Finally of course a feature should not compromise the safety of the whole program. So seems like they're on the same wavelength as you are.
rnijveld 3y ago
Definitely one of the things that is on our radar! Lots of features in sudo are just basically legacy features, remnants from the 90s or 00s that are no longer necessary in a modern setup, but nevertheless exist because in past times they used to be the default or only option. We are particularly aware of how much power a suid binary has, so we do try to be cautious!

musicale 3y ago

A few years back I was annoyed that sudo would consistently crash with a memory error.

rurban 3y ago

Memory safety would be good, but why then use a memory unsafe language?

PeterWhittaker 3y ago
Correct me if I am wrong, but isn’t Rust unsafe only when explicitly using unsafe? Provided this project does not do that, it would be memory safe, no?
- rurban 3y ago
  Look up their bugreports for stack overflow, besides unsafe blocks everywhere.
- johnisgood 3y ago
  Anything more than hello world is full of unsafe blocks. You need it. In any case, Ada/SPARK would be the most ideal choice for a "safe" language, not Rust. So tiring.
  - pdimitar 3y ago
    Indeed, this hate is very tiring to find on such threads. Consider not caring. I'll try to do the same.
    - johnisgood 3y ago
      Is my statement considered hate? Is it not the truth, though? Any projects I pick, including Rust's standard library, there are unsafe blocks everywhere, and as a Rust developer has said, those blocks do affect code outside of it.
      - pdimitar 3y ago
        Not this one in particular. It's your tone in this entire thread in general.

notorandit 3y ago

> But because it's written in C, sudo has experienced many vulnerabilities related to memory safety issues. Or because it's not been developed with enough care? I for one think that there is no unsafe language, only careless programmers.

actionfromafar 3y ago
Right! Like with airplanes, there are no unsafe airplanes, only careless pilots.
- stephc_int13 3y ago
  This analogy is completely wrong. The programmer would be the aero engineer, not the pilot. The pilot would be the sysadmin, maybe?
justin_oaks 3y ago
> there is no unsafe language Perhaps you didn't intend it this way, but that implies that there is no difference in safety between languages. This is a patently absurd idea. C is clearly less safe than many languages that don't allow unsafe memory practices.
rnijveld 3y ago
I think your expectations are too high. During our initial exploration we actually managed to talk to Todd Miller, the maintainer of sudo. In our (brief) interactions with him he did not sound cavalier like this at all. Instead I think that a lot of the issues with sudo are more about it being a thirty+ year old program and codebase, and sometimes features turn into bugs and security issues all on their own in such time periods. But then again, C just cannot offer the kinds of protections that Rust can, and mistakes will be made eventually by every human, better to have some protection from your mistakes than none at all.

stephc_int13 3y ago

This so-called memory safety is looking like a buzzword engineered to be extremely appealing to a type of mildly technical but mostly illiterate about computer security kind of people. This has been said before, this has been tried before, OOP was also seen as silver bullet at some point, like several others. Computer security is a deeply complex and dirty field, switching programming language won’t help much if programmers are expecting the work to be done for them by the compiler. If you want robust code : hire experts in the field and pay the price. Rewriting sudo is almost certainly going to be painful and to increase the vulnerabilities potential.

cedilla 3y ago
Alright, I'll take the obvious bait. The experts in the field are right over there, getting paid to rewrite it in rust.
- stephc_int13 3y ago
  Experts with Rust? Experts about sudo implementation requirements? Or computer security experts? Because you’ll probably need all of that.
rnijveld 3y ago
I’m on the team that is creating sudo-rs. I agree that just assuming that memory safety will get rid of all the bugs is just plain wrong, it will prevent some particular classes of bugs, but that is all it does. But we do think that sudo in particular suffers from being a really old codebase, and that especially on that point we can make progress. Sudo has lots of features no longer relevant. It has a plugin interface, but that interface uses almost exclusively strings in `key=value` format, and the plugin boundaries aren’t perfect either. It has behaviors that probably almost nobody relies on and yet add complexity and increase the attack surface. If we wanted to do something about that it would mean rewriting large parts of sudo. So if we’re re-implementing sudo anyway, why not start at the basics and build it a little better. Aside from the memory safety I think that is one of our main goals: make a simpler sudo that still has lots of the expressiveness. I hope you agree that cleaning up sudo is a good thing, and if we are doing that, we might as well take some memory safety along for the ride.

jacooper 3y ago

Another tool getting reimplemented in Rust under a weak license. Do people want to ruin the Linux Eco system or what? It only takes on distro to close its modified source(backports, bugfixes etc) for the entire Eco system to start to crack.

johnisgood 3y ago
Don't worry, there will be at least one distro using C and exclude Rust completely, or at least I'd hope so. Too bad the Linux kernel has Rust in it.
- jacooper 3y ago
  The problem isn't the language, its the license.

pyuser583 3y ago

This just isn’t necessary. There’s excellent C tooling that identifies memory safety issues. It seems any program that meets the four criteria would better served by rigorous analysis of the existing code.

johnisgood 3y ago
Indeed. This Why Not Rewrite It In Rust (RIIR) is absurd. I question their competency with regarding to C. I suppose they are just regurgitating each other's sentences without actually looking much into C and related tooling. That, or Ada/SPARK.
- pdimitar 3y ago
  Ada/SPARK has fallen behind on the rich library ecosystem. I've vetted it once about 7 months ago. I don't dig the syntax but that's 98% irrelevant; professionals shouldn't care about it. However, the lack of stuff I take for granted when working with several other languages, Rust included, drove me away. Nobody is paying me to enrich an ecosystem (even though I'd gladly take the opportunity to do so for a few languages I hold dear). --- On the regurgitating part, I feel obliged to point out that you're doing exactly the same as those you accuse of doing it. Rust is making strides and extremely serious engineers and decision makers are using and recommending it: part of the Linux kernel community, France's intelligence agency, Google's Android and Fuchsia projects, a lot of Fintech companies, and many others. You and others being eternally skeptical and feeling the need to insult adopters sounds like you just want people off your lawn without an objective analysis. And without taking feedback from companies who successfully adopted Rust and wrote good blog posts with both pros and cons. I'd question your competence if you think you know better than Google, Linux kernel devs and GCHQ. It's your right to echo-chamber yourself, the world keeps moving though.
  - johnisgood 3y ago
    According to your other answers, you have already concluded that opposing RIIR is due to a hatred for Rust. I doubt there will be any convincing of you, I did attempt it when I replied to one of your comments. > I'd question your competence if you think you know better than Google, Linux kernel devs and GCHQ. Could I not say the same though? Ada is used in avionics, air traffic control, railways, banking, military and space technology, i.e. critical software. Are they wrong but they do not know it yet? Should they switch to Rust? Either way, I find your conclusions questionable.