On Monday, January 31, 2022 5:36:24 AM EST 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, For security reasons, we count on these last two. We count on a property called non-repudiation. We also count on a user with a specific selinux user cannot escape that assigment. > 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. But doesn't satisfy our security requirements. If the kernel dbus project had been successful, then Linux would have had a rock solid basis to allow impersonation which would satisfy the security requirements and allow the desktop actually go through a common criteria certification if any one ever wanted to do that. But as it stands, anything created by IPC is missing the necessary security context. Also, it's impossible to reason about what's allowed and what's not because the policy is free-form javascript rather than assignments that can be checked by any configuration scanners. And access decisions do not go through the audit system. So, we really have little insight into access control and information flows from anything using IPC started applications. Setuid may be distasteful to some people. But it's properties are well known and its fully plumbed to make some assurance arguments about the platform. Cheers, -Steve _______________________________________________ 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
