3 ms·

Rewriting sudo is a weekend project*. Getting people to adopt it is a many-year political campaign.

by im3w1l 6y ago

toyg 6y ago
You can bet your last dollar that if the "right" RedHat or Debian developer rewrote sudo with feature parity, it would be adopted by all major distros in a couple of months. It's the sort of thing nobody really cares about except OpenBSD (which wrote their own). The problem is feature parity. Most rewrites cannot guarantee that off-the-bat, so they end up struggling to persuade people to switch - why break stuff that works just fine and lose features, in the name of some engineering purity?
- axaxs 6y ago
  Poettering to save the day with systemd-sudo?
  - magicalhippo 6y ago
    https://www.youtube.com/watch?v=TkR9QWuoyJ8 https://www.youtube.com/watch?v=TkR9QWuoyJ8
  - kuschku 6y ago
    Polkit-exec (pkexec) already exists, has much better security, and integrates with your DE instead of expecting passwords on the terminal.
    - deckard1 6y ago
      This thing? https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/programs/pkexec.c https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/s... Which also seems to not have tests. In fact, the only tests I'm seeing are from 2 years ago. https://gitlab.freedesktop.org/polkit/polkit/-/tree/master/test/polkit https://gitlab.freedesktop.org/polkit/polkit/-/tree/master/t... > has much better security It's using D-bus. My faith in D-bus security is close to my faith in seeing a fresh Linux install with zero D-bus error messages from apps. Which is to say, nonexistent. > integrates with your DE instead of expecting passwords on the terminal. There's nothing inherently insecure about passwords on the terminal, and certainly nothing a DE can do better. I have yet to see a display manager or lock screen app that knows what the hell PAM is doing. Try doing even the simplest things with PAM, such as getting a fingerprint reader or Yubikey working, and every single display manager simply chokes. I'm not sure which is more of a Byzantine mess: Linux authentication and authorization, or Linux audio.
      - megous 6y ago
        PAM is fun. https://github.com/systemd/systemd/issues/16813 https://github.com/systemd/systemd/issues/16813 With all the .so modules loading into some process, etc. Some questionable design in sshd makes it lock up completely for all incoming connections when used with PAM and when pam module ends up in infinite loop. Nevermind that systemd pam modules pull in a shitton of stuff, including dbus, into any process that tries to use PAM for auth, these days. I guess it all runs as root, too. sshd at least tries to fork a child for all this and waits for it and kills it, so that the parent process can't be polluted. It just has no timeout when waiting for result, and doesn't accept further connections when waiting. Sometimes it's better not to look too deep under the covers.
        eklitzke 6y ago
        How else would you implement PAM? The whole point is that you can write arbitrary code to implement whatever custom authentication policy you have, so it needs to be able to dlopen things. And if you don't like the PAM policy written by your distro, you're free to change it by implementing your own authentication policies, or dropping things you don't care about (like systemd, you can configure PAM to just use /etc/passwd and /etc/shadow if you like). sshd needs to run as root (obviously) because it grants login shells to people, so it needs to run in a privileged context. And the PAM modules it executes also need to be run as root, because PAM modules need to do things like read /etc/shadow.
        JoachimSchipper 6y ago
        https://man.bsd.lv/login.conf.5#AUTHENTICATION https://man.bsd.lv/login.conf.5#AUTHENTICATION documents OpenBSD's system, which revolves around running /usr/libexec/auth/login_<foo>. OpenBSD's system doesn't let you do the stack-of-libraries thing that PAM does, but having one binary is a lot simpler. (In the past, OpenBSD had a login-locally-or-via-Kerberos binary there, which does show the downside of that approach over PAM's more flexible approach.)
    - vbezhenar 6y ago
      Does it work without GUI?
rogerbinns 6y ago
That would indeed be a huge feat of programming skill! I refer you to the configuration file documentation to treat as a spec: https://www.sudo.ws/man/1.8.3/sudoers.man.html https://www.sudo.ws/man/1.8.3/sudoers.man.html Implementing a subset of sudo is a weekend project, for some values of useful.
- jeffbee 6y ago
  That's part of the dark outcome of so many untested features: it makes it easy to cast FUD upon any potential replacements. As we have no black-box test suite that shows `sudo` implements all of these features, so we also cannot have faith that any replacement would. Ideally it should be possible to run sudo's black box tests against any potential replacement. To start with, we need those tests.
  - arp242 6y ago
    There are actually a bunch of tests for the sudoers file format.
- masklinn 6y ago
  > Implementing a subset of sudo is a weekend project, for some values of useful. openbsd dropped sudo for "weekend project" `doas`, in no small part because it does not support most of that stuff. Here's the configuration file documentation: https://man.openbsd.org/doas.conf.5 https://man.openbsd.org/doas.conf.5
stouset 6y ago
This is why OpenBSD has `doas`.

Rewriting sudo is a weekend project*. Getting people to adopt it is a many-year political campaign.

by im3w1l 6y ago

Rewriting sudo is a weekend project*. Getting people to adopt it is a many-year political campaign.

toyg 6y ago

You can bet your last dollar that if the "right" RedHat or Debian developer rewrote sudo with feature parity, it would be adopted by all major distros in a couple of months. It's the sort of thing nobody really cares about except OpenBSD (which wrote their own). The problem is feature parity. Most rewrites cannot guarantee that off-the-bat, so they end up struggling to persuade people to switch - why break stuff that works just fine and lose features, in the name of some engineering purity?

axaxs 6y ago
Poettering to save the day with systemd-sudo?
- magicalhippo 6y ago
  https://www.youtube.com/watch?v=TkR9QWuoyJ8 https://www.youtube.com/watch?v=TkR9QWuoyJ8
- kuschku 6y ago
  Polkit-exec (pkexec) already exists, has much better security, and integrates with your DE instead of expecting passwords on the terminal.
  - deckard1 6y ago
    This thing? https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/programs/pkexec.c https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/s... Which also seems to not have tests. In fact, the only tests I'm seeing are from 2 years ago. https://gitlab.freedesktop.org/polkit/polkit/-/tree/master/test/polkit https://gitlab.freedesktop.org/polkit/polkit/-/tree/master/t... > has much better security It's using D-bus. My faith in D-bus security is close to my faith in seeing a fresh Linux install with zero D-bus error messages from apps. Which is to say, nonexistent. > integrates with your DE instead of expecting passwords on the terminal. There's nothing inherently insecure about passwords on the terminal, and certainly nothing a DE can do better. I have yet to see a display manager or lock screen app that knows what the hell PAM is doing. Try doing even the simplest things with PAM, such as getting a fingerprint reader or Yubikey working, and every single display manager simply chokes. I'm not sure which is more of a Byzantine mess: Linux authentication and authorization, or Linux audio.
    - megous 6y ago
      PAM is fun. https://github.com/systemd/systemd/issues/16813 https://github.com/systemd/systemd/issues/16813 With all the .so modules loading into some process, etc. Some questionable design in sshd makes it lock up completely for all incoming connections when used with PAM and when pam module ends up in infinite loop. Nevermind that systemd pam modules pull in a shitton of stuff, including dbus, into any process that tries to use PAM for auth, these days. I guess it all runs as root, too. sshd at least tries to fork a child for all this and waits for it and kills it, so that the parent process can't be polluted. It just has no timeout when waiting for result, and doesn't accept further connections when waiting. Sometimes it's better not to look too deep under the covers.
      - eklitzke 6y ago
        How else would you implement PAM? The whole point is that you can write arbitrary code to implement whatever custom authentication policy you have, so it needs to be able to dlopen things. And if you don't like the PAM policy written by your distro, you're free to change it by implementing your own authentication policies, or dropping things you don't care about (like systemd, you can configure PAM to just use /etc/passwd and /etc/shadow if you like). sshd needs to run as root (obviously) because it grants login shells to people, so it needs to run in a privileged context. And the PAM modules it executes also need to be run as root, because PAM modules need to do things like read /etc/shadow.
        JoachimSchipper 6y ago
        https://man.bsd.lv/login.conf.5#AUTHENTICATION https://man.bsd.lv/login.conf.5#AUTHENTICATION documents OpenBSD's system, which revolves around running /usr/libexec/auth/login_<foo>. OpenBSD's system doesn't let you do the stack-of-libraries thing that PAM does, but having one binary is a lot simpler. (In the past, OpenBSD had a login-locally-or-via-Kerberos binary there, which does show the downside of that approach over PAM's more flexible approach.)
  - vbezhenar 6y ago
    Does it work without GUI?

rogerbinns 6y ago

That would indeed be a huge feat of programming skill! I refer you to the configuration file documentation to treat as a spec: https://www.sudo.ws/man/1.8.3/sudoers.man.html https://www.sudo.ws/man/1.8.3/sudoers.man.html Implementing a subset of sudo is a weekend project, for some values of useful.

jeffbee 6y ago
That's part of the dark outcome of so many untested features: it makes it easy to cast FUD upon any potential replacements. As we have no black-box test suite that shows `sudo` implements all of these features, so we also cannot have faith that any replacement would. Ideally it should be possible to run sudo's black box tests against any potential replacement. To start with, we need those tests.
- arp242 6y ago
  There are actually a bunch of tests for the sudoers file format.
masklinn 6y ago
> Implementing a subset of sudo is a weekend project, for some values of useful. openbsd dropped sudo for "weekend project" `doas`, in no small part because it does not support most of that stuff. Here's the configuration file documentation: https://man.openbsd.org/doas.conf.5 https://man.openbsd.org/doas.conf.5

stouset 6y ago

This is why OpenBSD has `doas`.