This seems worthwhile at first sight; another implementation (in a different language) gives us more choice and time will tell on the CVE count:user ratio.
I assume the more unsafe rust used, the more the CVE numbers will appear like C and C++. People like to say unsafe means "I checked this and this is fine, compiler" and isn't a bad thing but I feel that's inaccurate since the whole point of rust is that people struggle to write safe code even when they are really checking. I feel unsafe rust is way more "I really hope this is right, but I have minimized it to just this area out of necessity, since it likely isn't."
I would like to see how much CVEs go down over time. The fact sudo is being rewritten suggests that even after long periods of use, security issues popping up is still a common-ish problem?
It seems to average out at a bit over 1 per year over the last 20 years, based on [1]; is that "a lot"? I guess?
It's worth pointing out that while there certainly are memory-related C-style issues, quite a few are logic errors because all of this is rather subtle once you start adding features beyond what e.g. "doas" does. For example the recent "Sudoedit can edit arbitrary files"[2] is a somewhat subtle interaction between sudoedit, environment variables, and flag parsing. Previously there was [3] and [4] from 2004 and 2010.
Will memory safety be a benefit? Of course it will. But I think these kind of issues are the real challenge here. A drop-in replacement for "sudo" is useful, but I have to wonder if it wouldn't be better to rethink the approach from first principles, taking 40 years of sudo lessons in to account. It's also surprisingly easy to shoot yourself in the foot with a wrong sudoers file, which is not strictly a security issue in sudo as such but also something that can probably be improved on?
That 2023 sudoedit bug has been in sudo since 1.8, released in 2011, and Todd has been maintaining sudo since 1994, and he's actually pretty good as well as experienced with this kind of stuff. Yet he still missed it, as did everyone else, for well over ten years. It seems there are far more structural problems in the entire approach that go well beyond "C is not memory safe". That's certainly an issue, but in a way seems almost banal compared to the deeper issues.
[1]: https://www.sudo.ws/security/advisories/
[2]: https://www.sudo.ws/security/advisories/sudoedit_any/
[3]: https://www.sudo.ws/security/advisories/sudoedit_escalate2/
That doesn't mean it's impossible to write correct unsafe code, it's just not as obvious as "trust me bro I know better than borrowck." You can't actually elide the invariants Rust upholds, you just have to take over from the compiler when it can't prove them.
(1) https://doc.rust-lang.org/reference/behavior-considered-unde...
It's bad to think on security by just using a language.
My c compiler does not connect to internet during compiling.
Do you not have to install said dependency from the Internet and start (at least part of) the compile over?
Rust's build system, Cargo, does however. And many C build systems do as well, e.g. https://cmake.org/cmake/help/latest/guide/using-dependencies...
ifconfig eth0 down
before compiling to avoid such issues.
Wouldn't it be the static or dynamic linked libraries for the particular program in question?
There is a crt.0 "C Runtime" object. This is code that is literally run "at runtime". When you execute a binary, the C runtime is the first thing executed to setup the stack and call main().
This is just a bit of assembly that runs before main(). It shares ~nothing in common with "runtime" languages like Python or Java where the runtime is alive during the whole program's execution.
The C run time does not handle floats or threads or anything like that. Software floats are dealt with by the compiler and threading is implemented as its own library (either in userspace or built into the kernel).
https://learn.microsoft.com/en-us/cpp/c-runtime-library/c-ru...
It doesn't matter what people think, rather the CS point of view of a language runtime is.
That library is the runtime.
C implementation without the respective runtime is what is called a freestanding implementation as per ISO C.
This was a good name at the time. Its a bit of code that gets executed literally "at runtime". When you run a program, this object gets invoked to setup the stack and call main(). Its just a bit of assembly.
Then, decades later, languages like Java overloaded the term "runtime" to refer to their interpreter / vm. This causes confusion to this day, evidently.
It's funny how rust is praised as secure without any code audit.
https://github.com/RustSec/rustsec/tree/main/cargo-audit
https://mozilla.github.io/cargo-vet/
Besides, every dependency is locked.
Rust improves or eliminates some issues, but that does not imply that other issues are magically solved.
Nobody is suggesting that a language solves all security issues.
It does have much better memory safety than C, which is the cause of the majority of security issues.
(0) https://prev.rust-lang.org/en-US/faq.html#does-rust-have-a-r...
"Rust is blazingly fast and memory-efficient: with no runtime or garbage collector" [0]
I guess it depends on what you mean by a runtime. Panic handlers and initialisation code is a pretty small runtime.