There's been cases[1], of particular note, the unescape overflow one[2]. This one scathed the reputation of sudo enough to get people pushing for alternatives such as doas. The track record of vulnerabilities in general leaves a bit to be desired, even outside of memory vulns.
Sudo had quite a few problems with security, partially because of this doas was developed for BSD.
Some problems come from the huge amount of features(ldap, easter eggs, ...).
sudo-rs reduces the problems by not implementing those features.
> Some problems come from the huge amount of features(ldap, easter eggs, ...). sudo-rs reduces the problems by not implementing those features.
This makes me wonder:
1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
2) If these features are useful in the real world, will a Rust rewrite of sudo inevitably gain these features over time and end up with similar problems?
doas is 500 lines of C. Two orders is magnitude less than sudo yet still covers the core functionality. Sure you could grandfather”s axe your way into the final product, but difficult to see how a a hypothetical code base 1% of the original counted as anything but a rewrite.
2. While a feature may be useful, the question is how useful, and to how many people. sudo-rs is removing features that aren't used very much, if at all, and doesn't plan to add them, to combat this. Those users can still use the original sudo.
Ubuntu moving to a memory safe sudo implementation isn't actually that concerning to me. It's a good idea to have a smaller, safer sudo alternative as the default, as OpenBSD does with doas. Users can install sudo if they need it. My problem is that it needs to specifically be called something else than sudo. Again OpenBSD has doas, which to the users clearly isn't sudo, so users don't expect it to behave as sudo or configure as sudo.
By all means, write a better, safer, smaller, more secure version of sudo, but don't have command be sudo or sudo-rs, name it something else.
Debian is currently in the process of dropping the direct LDAP support in sudo, in favor of sssd. From sudo's NEWS.Debian.gz:
> In practice, there are few installations that use sudo-ldap. Most installations that use LDAP as a directory service and sudo have now opted for sssd, sssd-ldap and libsss-sudo.
> The Debian sudo team recommends the use of libsss-sudo for new installations and the migration of existing installations from sudo-ldap to libsss-sudo and sssd.
The features we specifically don’t support are those related to direct LDAP support within sudo, so things like loading a sudoers file directly from LDAP. Sudo-rs will use any user retrieved via NSS, such as when configured using SSSD to load LDAP users. And from the authentication side you can use whatever PAM supports, so anything like Kerberos etc, which again can be coupled with the same LDAP database.
[1]: https://www.sudo.ws/security/advisories/
[2]: https://www.sudo.ws/security/advisories/unescape_overflow/