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.
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.
I'm pretty sure this is just trying to stir people up, but we have lots of evidence that memory unsafety is the cause of the majority of vulnerabilities in widely deployed systems that are written in unsafe languages, and these vulnerabilities are often much more severe.
Refusing to accept or acknowledge scientific evidence is something that I would not expect from a security expert (or any expert).
Comments
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.
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.
There are risks, good old second system syndrome, but sudo is probably small enough to try.
Is it really broken though?
Improving the codebase could be simpler and safer, but less marketable maybe…
I'm pretty sure this is just trying to stir people up, but we have lots of evidence that memory unsafety is the cause of the majority of vulnerabilities in widely deployed systems that are written in unsafe languages, and these vulnerabilities are often much more severe.
Refusing to accept or acknowledge scientific evidence is something that I would not expect from a security expert (or any expert).
Alright, I'll take the obvious bait.
The experts in the field are right over there, getting paid to rewrite it in rust.
Experts with Rust? Experts about sudo implementation requirements? Or computer security experts? Because you’ll probably need all of that.