sudo & su Being Rewritten In Rust For Memory Safety

[mirmirmir]

big companies are using rust as an excuse to replace strict lisences like gpl with lisence they can get away with when they decide to be an asshole, so linux-rs would be another bsdeez 🙄🙄

[jarekZ]

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

initiatives like this are PR to get funding, first and foremost. As for real software, there's doas, for example. Just around 2k lines of code, i.e. almost no space to make CVE's - which is the real way to increase code security and reliability (unlike of RiiR)

[archkde]

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?

They aren't, but neither are the Linux kernel, glibc and even sudo itself (I'm honestly a bit surprised about the latter). That said, nothing really stands out as potentially being a problem (at most clap and syslog) outside of malicious intent (see below). I'm much more worried about their sloppy attitude regarding the configuration parser.

Rust alone provides just one kind of safety. All these people are assuming it's some kind of magic bullet.

I literally don't remember even a single statement claiming this, outside of very obvious jokes and straw mans by Rust haters. Rust provides memory safety, and it somewhat helps with other aspects of safety. No one claims more.

The ecosystem is convenient, but it's a major "leftpad" in their security.

The usual approach in Rust is to lock your dependencies, specifying a version and a cryptographic hash. Versions once published on crates.io can be neither deleted nor modified, and even if they were, the hash would mismatch and the attack would be detected. So "left-pad" (the author unilaterally deleting their package) can literally not happen, and even if it would, it's only an availability issue, not a security one.

Now the authors of the software pulling a malicious or vulnerable dependency could absolutely happen. Ideally they would audit every depency, but we all know that this is not done. On the positive side, there is the RustSec database of published vulnerabilities in published crates, and I think even npm has something similar nowadays.

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.

You obviously have no idea why Rust was stripped down in order to be included in the kernel. It has nothing to do with "mission critical applications" (lol, I'd probably use seL4 or something there, but certainly not Linux anyway). The reason is actually the same why Linux doesn't use the C standard library either: most functionality of std simply makes no sense inside a kernel.

[archkde]

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!

Microsoft actually tried something like that years ago, it was called Singularity and written in a dialect of C#.

[archkde]

initiatives like this are PR to get funding, first and foremost. As for real software, there's doas, for example. Just around 2k lines of code, i.e. almost no space to make CVE's - which is the real way to increase code security and reliability (unlike of RiiR)

I agree that doas is likely better than this project. A RIIRed doas might be even better, but the security of doas is mostly already limited by PAM. So the takeaway is, RIIR PAM

[dimko]

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!

yada yada yada, microkernel, smth smth.

[MorrisS.]

What's the percentage of the reduction? How much can be written in Rust?

[piotrj3]

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.

Yes but in context of sudo we had plenty of CVEs related to issues that mostly wouldn't happen in Rust.I think security critical aplications are excellent use cases for rust. Seriously i wouldn't even mind if they were written in even more security critical language like SPARK

[unwind-protect]

big companies are using rust as an excuse to replace strict lisences like gpl with lisence they can get away with when they decide to be an asshole, so linux-rs would be another bsdeez 🙄🙄

Good.

[ssokolow]

I agree that doas is likely better than this project. A RIIRed doas might be even better, but the security of doas is mostly already limited by PAM. So the takeaway is, RIIR PAM

Funny you should say that. There was a RustConf 2022 talk named The Sheer Terror of PAM.