8 ms·

Did sudo have memory problems? Did it ever fail because it didn't handle its memory correctly?

stop50 1y ago
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.
- XorNot 1y ago
  Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.
  - Filligree 1y ago
    Those people can keep using sudo; it’s not going away. The rest of us get better security.
    - immibis 1y ago
      Having to type doas on systems without LDAP and sudo on systems with LDAP is abstraction leakage.
  - fluidcruft 1y ago
    Is it actually removing ldap or is it offloading to pam?
  - JoshTriplett 1y ago
    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 1y ago
      Ah that makes more sense.
  - dec0dedab0de 1y ago
    Could you clarify what you mean by more important sudo deployments?
  - rnijveld 1y ago
    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.
- ch_123 1y ago
  > 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 1y ago
    > 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 https://en.wikipedia.org/wiki/Doas
    - Dylan16807 1y ago
      "without a rewrite" means cutting down the existing code. A completely different program goes into the same category as "rewrite".
      - 0cf8612b2e1e 1y ago
        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 1y ago
        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".
  - literalAardvark 1y ago
    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.
- mrweasel 1y ago
  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.
mid-kid 1y ago
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. [1]: https://www.sudo.ws/security/advisories/ https://www.sudo.ws/security/advisories/ [2]: https://www.sudo.ws/security/advisories/unescape_overflow/ https://www.sudo.ws/security/advisories/unescape_overflow/
Maxatar 1y ago
Yes it has: https://nvd.nist.gov/vuln/detail/cve-2021-3156 https://nvd.nist.gov/vuln/detail/cve-2021-3156

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.

XorNot 1y ago
Removing LDAP is a huge problem for the more important sudo deployments though: centralized management of permissions is kind of a vital function.
- Filligree 1y ago
  Those people can keep using sudo; it’s not going away. The rest of us get better security.
  - immibis 1y ago
    Having to type doas on systems without LDAP and sudo on systems with LDAP is abstraction leakage.
- fluidcruft 1y ago
  Is it actually removing ldap or is it offloading to pam?
- JoshTriplett 1y ago
  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 1y ago
    Ah that makes more sense.
- dec0dedab0de 1y ago
  Could you clarify what you mean by more important sudo deployments?
- rnijveld 1y ago
  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.
ch_123 1y ago
> 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 1y ago
  > 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 https://en.wikipedia.org/wiki/Doas
  - Dylan16807 1y ago
    "without a rewrite" means cutting down the existing code. A completely different program goes into the same category as "rewrite".
    - 0cf8612b2e1e 1y ago
      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 1y ago
        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".
- literalAardvark 1y ago
  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.
mrweasel 1y ago
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.

mid-kid 1y ago

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. [1]: https://www.sudo.ws/security/advisories/ https://www.sudo.ws/security/advisories/ [2]: https://www.sudo.ws/security/advisories/unescape_overflow/ https://www.sudo.ws/security/advisories/unescape_overflow/

Maxatar 1y ago

Yes it has: https://nvd.nist.gov/vuln/detail/cve-2021-3156 https://nvd.nist.gov/vuln/detail/cve-2021-3156