On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) wrote: > 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. If you do privileged execution of specific operations via IPC you get 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. (But I guess that ship has sailed, getting sudo out of the standard OS 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.) > 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. IRL you cannot clean up your execution context, because new stuff is added all the time. And often enough it's not even clear whar reset it to, e.g. cgroup stuff. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
