sudo & su Being Rewritten In Rust For Memory Safety

[phoronix]

Phoronix: sudo & su Being Rewritten In Rust For Memory Safety

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...

https://www.phoronix.com/news/sudo-su-rewrite-rust

[saladin]

Neat, but this looks like an dependent rewrite that just started development. It'll take a while after reaching feature parity for distros to start packaging this over the 'real' sudo.

Part of that is that the 'real' sudo is established and well studied. This is not. It's an uphill battle for these devs to get this adopted, and I wish them all the best.

[bearoso]

Rewriting for memory safety is all and good, but look at the list of third-party dependencies. Are all those audited properly to be included in a binary that is setuid root?

Rust alone provides just one kind of safety. All these people are assuming it's some kind of magic bullet. The ecosystem is convenient, but it's a major "leftpad" in their security.

Look at how stripped down rust is to be included in the Linux kernel. You have to give up a lot of the convenience for mission critical applications.

[Sethox]

Yeah, soon Flatpak is going to get a rust rewrite..

[archkde]

While I like being security-critical programs being written in memory-safe languages, I'm not convinced of this project. The hard parts of sudo, I think, are 1. parsing the sudoers file and 2. interfacing with PAM. Rust unfortunately cannot help with 2, and more critically, their approach for 1 seems to be "lol, we don't care about some incompatibilities". At that point, you may just as well use a more reasonable configuration syntax to begin with, and the problem becomes much simpler. Actually it might be even better, since silently incompatible parses of sudoers are a recipe for critical vulnerabilities dependent on system configuration.

[TemplarGR]

Eventually the Linux kernel will be rewritten in Rust for memory safety. It is known.

[kpedersen]

Eventually the Linux kernel will be rewritten in Rust for memory safety. It is known.

Once the kernel is rewritten in Rust, we won't even need su or sudo. We can just run everything as root and it will all be safe!

[meklu]

Once the kernel is rewritten in Rust, we won't even need su or sudo. We can just run everything as root and it will all be safe!

Not even that, we can run all code in kernel mode instead of user mode. Think of all the efficiency savings we get from eliminating mode switches!

[EvilHowl]

initiatives like will make people think that anything that is written in C or C++ is automatically memory unsafe and buggy and everything that is written in Rust is automatically memory safe and not buggy.

That will hurt Rust in the long run.

[stormcrow]

Rewriting for memory safety is all and good, but look at the list of third-party dependencies. Are all those audited properly to be included in a binary that is setuid root?

Rust alone provides just one kind of safety. All these people are assuming it's some kind of magic bullet. The ecosystem is convenient, but it's a major "leftpad" in their security.

Look at how stripped down rust is to be included in the Linux kernel. You have to give up a lot of the convenience for mission critical applications.

Dependency management is only superficially about the list of dependencies pulled in by a project. Granted, the longer the list, the more annoying it is to build and maintain. However, that doesn't necessarily mean automatic safety problems. The reason the scope of Rust dependencies in OS kernels is restricted is because you usually want a kernel to be as self contained as possible while till meeting the norms associated with that kind of environment.

My point is, just because package Y, which project X depends on, has a security vulnerability, even a critical one, that doesn't necessarily follow that X executable has that same vulnerability in practice. X must also use the code path that the security vulnerability is part of. If it doesn't, then the likelihood of that vulnerability affecting X is nil.

The details of how that occurs is different from one language environment and ecosystem to the next, but it's easy enough explained with Python. In Python, just because you have a dependency on Pandas, that doesn't mean all programs using Pandas are equally vulnerable to a security flaw. You can chose to only import classes and functions from modules that you want, and leave the rest on the table unused, and therefore never affecting your program. However, most vulnerability scanners, some less skilled or ethical research groups and individuals, and many of the enthusiast community and general public automatically draw the often inaccurate assumption that because a program depends on a certain library or module, then it must follow all programs that depend on it are equally vulnerable.

Similarly, I've seen a lot of people in the open source world that often fall prey to the fallacy that vi/emacs and a compiler/interpreter are the only tools they need to write secure programs - if they care about security to begin with. This is incorrect. It's even provably incorrect given the number of vulnerabilities increasingly exposed in open source environments - yes including that bastion of security OpenBSD. There are many tools developed over 5 decades of computer science and programming language theory that help dealing with memory safety, input safety, logic flow and safety, and scope that are often ignored if not ridiculed by theoretical veteran programmers (I know from experience). And yet a simple logic flow chart can often reveal fundamental logic errors with not a lot of effort when properly executed. It's down right scary just how hostile some programmers can be to fundamental tools - and I don't necessarily mean debuggers and IDEs, but fundamental pen and paper tools like logic analysis and mathematical proofs that could identify problems before anyone gets to writing code.