[3a2d29]

Yeah agree with this, will be interesting to see.

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?

[arp242]

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

[4]: https://www.sudo.ws/security/advisories/sudoedit/

[duped]

That's a really good point that I feel like isn't talked about enough. Unsafe rust is a lot harder to write correctly than bog standard C, because you have to uphold the invariants to avoid undefined behavior (1). It's why there's a whole ebook about it (2).

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

(2) https://doc.rust-lang.org/nomicon/

[snovv_crash]

Another critical consideration of this is that if you make a mistake in unsafe rust code it could manifest itself as a 'bug' in the 'safe' rust code due to invariants that the safe code depends on not being upheld. It is literally undefined behaviour, in the "rm -rf / and insult your mother" sense.

[lamontcg]

Why would sudo/su need a lot of tricky unsafe code?

[AnIrishDuck]

Using grep, it looks like they mostly use unsafe code to interface with existing C libraries. In those cases it's roughly as tricky as writing C in the first place IMO, so still probably a net win.