Florian Weimer writes:
> Well, that's precisely the problem that PK was supposed to
> but then it descended down the JS rabbit hole...
Not sure if we are talking about the same thing. I meant flooding the
local socket (or similar) with requests, not access control.
Create a filesystem socket. Set the socket's UID, GID, and chmod.
Abracadabra: same initial access control as execve. I don't recall off the
top of my head whether you need r, w, x, or some combination of these to be
able to connect() to it, but whatever they are: set it. I also don't recall
whether ACLs would also work, but at least without ACLs you get the same
level of control as an executable binary.
Then, demand an SO_PASSCRED as the first order of business, on every new
connection: now you have exactly the same information to work with as a SUID
I can't think of any reason why su/sudo cannot be implemented this way.
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.
suid is not the problem. An execved program will inherit the environment,
some open file descriptors, and maybe a few other things that a standalone
daemon that accepted a socket connection does not have. But that's what most
exploits leverage, so cleaning up the environment and open file descriptors
would remedy that. It will take some effort to exploit whatever remains.
If you wrote a suid program, and did not wipe out your char **environ, or
went through and closed any lingering file descriptors, your problem was not
your suid bit, but something else.