I said it before and I'll say it again, probably not for the last time: people who really care about security would take a long, hard look at the *design* of sudo, where its weaknesses are, why it is so hard to make secure. (Hint: it's the genericity and the sudoers file syntax.)
They would write other, better tools to implement privilege escalation, and they'd have a better time ensuring it's secure. They could even write them in a memory-safe language, if they consider that it's important.
But taking *sudo* as is, not questioning its interface, and simply rewriting it in Rust, only screams "we don't care about having a holistic approach to security, we just hate C".
I said it before and I'll say it again, probably not for the last time: people who really care about security would take a long, hard look at the *design* of sudo, where its weaknesses are, why it is so hard to make secure. (Hint: it's the genericity and the sudoers file syntax.)
They would write other, better tools to implement privilege escalation, and they'd have a better time ensuring it's secure. They could even write them in a memory-safe language, if they consider that it's important.
@ska@social.treehouse.systems so what your saying is
rewrite doas in rust!
@ska@social.treehouse.systems most rewrites in rust actually change the interface in such cases though?
@ska @tychotithonus the downside of building a new tool with new semantics and configuration format is that in 20 years' time, it might have gotten sufficient adoption to start being considered as a replacement. Network effects aren't just for fax machines and social networks, after all.
The announcement blog post claimed 1/3 of sudo security bugs have been memory safety, so as long as the rewrite didn't introduce at least that many new bugs elsewhere, it's presumably a net-win.