[stop50]

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.

[ch_123]

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

[throw0101a]

> 1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?

OpenBSD did this with their doas utility:

* https://en.wikipedia.org/wiki/Doas

[Dylan16807]

"without a rewrite" means cutting down the existing code. A completely different program goes into the same category as "rewrite".

[0cf8612b2e1e]

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.

[Dylan16807]

Your phrasing sounds like you disagree with me, but you're saying the same thing, right? That doas is not an example of "without a rewrite".

[steveklabnik]

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.

[literalAardvark]

It can't end up with similar problems, due to the memory safety guarantee.

That's not to say that it won't create other ones.

[ch_123]

There are many types of security problems beyond memory safety issues.

[mrweasel]

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.

[XorNot]

Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.

[JoshTriplett]

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.

[XorNot]

Ah that makes more sense.

[rnijveld]

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.

[Filligree]

Those people can keep using sudo; it’s not going away. The rest of us get better security.

[immibis]

Having to type doas on systems without LDAP and sudo on systems with LDAP is abstraction leakage.

[fluidcruft]

Is it actually removing ldap or is it offloading to pam?

[dec0dedab0de]

Could you clarify what you mean by more important sudo deployments?