On 1/31/22 05:36, Lennart Poettering wrote: > 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. 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 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. 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 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.) 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. -- Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
