[Retr0id]

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]

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]

True, CVE-2021-4034 comes to mind as a recent example (exploiting zero-length argv)

[hedora]

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]

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

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

(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]

I think this post explains why much better than I can: 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.