3 ms·

A bug in a daemon-based sudo alternative would surely also result in privilege escalation? I think the main benefit of eliminating setuid binaries is that you

A bug in a daemon-based sudo alternative would surely also result in privilege escalation? I think the main benefit of eliminating setuid binaries is that you can forbid them system-wide (e.g. via mount flags), as a hardening measure.

JoshTriplett 2y ago
There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.
- Retr0id 2y ago
  True, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)
  - hedora 2y ago
    How is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket? The original unix process abstraction was extremely simple; the entire spec is a few pages. The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works. Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
    - Dylan16807 2y ago
      > How is that any different than a daemon that has a parser error in its message handler The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.
      - hedora 2y ago
        Assuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default). Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c https://github.com/TheMilkies/rut/blob/main/rut.c (Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list). The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell). There’s also the config file, but that’s the same for both. Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.
kokada 2y ago
I think this post explains why much better than I can: https://mastodon.social/@pid_eins/112353324518585654 https://mastodon.social/@pid_eins/112353324518585654. So yes, I am not saying that privilege escalation bugs are impossible if you have a different architecture, but like Lennart argues is that it makes them much more difficult to happen, especially because creating a proper setuid is difficult. Also there is a bunch of things that makes sudo especially tricky to implement correctly.

JoshTriplett 2y ago

There's value in always starting processes from a known-secure environment rather than attempting to transform a user's arbitrary environment into a secure one.

Retr0id 2y ago
True, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)
- hedora 2y ago
  How is that any different than a daemon that has a parser error in its message handler, except that the daemon could be misconfigured to listen on a network socket? The original unix process abstraction was extremely simple; the entire spec is a few pages. The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works. Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
  - Dylan16807 2y ago
    > How is that any different than a daemon that has a parser error in its message handler The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.
    - hedora 2y ago
      Assuming static linkage (which sudo has to assume), there’s really not much to parse. It should just be dealing with a null-delimited list (argv) and the caller’s environment variables (which it just needs to ignore and clear by default). Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c https://github.com/TheMilkies/rut/blob/main/rut.c (Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list). The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell). There’s also the config file, but that’s the same for both. Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.

kokada 2y ago

I think this post explains why much better than I can: https://mastodon.social/@pid_eins/112353324518585654 https://mastodon.social/@pid_eins/112353324518585654. So yes, I am not saying that privilege escalation bugs are impossible if you have a different architecture, but like Lennart argues is that it makes them much more difficult to happen, especially because creating a proper setuid is difficult. Also there is a bunch of things that makes sudo especially tricky to implement correctly.