On 1/31/22 05:36, Lennart Poettering wrote:
On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam(a)courier-mta.com)
> Having said all of that: the suid bit itself is irrelevant. It is nothing
> more than a convenient scapegoat to blame other bugs on. The same bug that's
> exploitable in a suid binary will also be exploitable, exactly the same way,
> in its suid-less equivalent. If you have a buffer overrun in a suid binary
> as a result of carefully-crafted command-line parameters or environment,
> then if you replace the suid binary with an identical bug-for-bug
> implementation that uses a socket to carefully pass along the same
> environment or parameters to a native root binary, and the buffer overrun is
> the same, guess what: you still have the same exploit.
I vehemently disagree. The thing with setuid/setgid is that the
invoked privileged process inherits a lot of implicit state and
context that people aren't really aware of or fully
understand. i.e. it's not just env vars and argv, it's cgroup
memberships, audit fields, security contexts, open fds, child pids,
parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
settings, tty control, signal masks + handlers, … and so on. And it's
not even clear what gets inherited as many of these process properties
are added all the time.
State inheritance definitely should be opt-in, with the possible
exception of certain audit data such as the audit user ID.
If you do privileged execution of specific operations via IPC you
the guarantee that whatever is done, is done from a well-defined,
pristine execution environment, without leaking context implicitly. The
IPC message is the *full* vulnerable surface, and that's as minimal as
it can get. And that's great.
So yes, setuid/setgid is a mess. Modern OS designs tend to follow the
rule that privs lost cannot be regained, and that's a much much better
design than what we do on Linux/UNIX.
Yes and no. Systems with capability-based access control allow
one to gain additional privileges by means of receiving privileged
capabilities. For instance, a login program could start with no
privileges at all other than the ability to connect to a service that
authenticates users. Upon successful authentication, the login program
would be given a capability that allowed it to act as the authenticated
user. For this to work, different instances of the login program would
need to be unable to compromise with each other, which is fairly easy
to enforce in a pure capability-based system.
(But I guess that ship has sailed, getting sudo out of the standard
is not going to work for a general purpose distro these days anymore —
but let's not pretend setuid/setgid was OK, because it's not.)
What would break if sudo was replaced by an IPC service that ran
sudo as if it was setuid root, without it actually being setuid root?
I imagine the hardest part would be TTY handling, as not being able
to Ctrl-C a command launched by sudo is a rather poor user experience.
That might be solvable, though.
Demi Marie Obenour (she/her/hers)