On Mo, 31.01.22 06:28, Sam Varshavchik (mr...@courier-mta.com) wrote: > > 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 none of that makes any difference, whatsoever, unless there's also an > underlying logical bug in the code itself.
That's what you hope. But because there are *so* many properties of a process these days, and it's not entirely obvious what gets inherited and what not and what the effect of it is, that it's very hard to clean it up, and I'd even claim impossible. > > > 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. > > Stuff that's "added all the time" won't be used in existing code base, and > will be immaterial. None of the stuff from semi-recent history (containers, > CPU affinities, etc…) appears to have much effect on my existing setup. suid processes didn't use to be a member of a cgroup. Now they are. Security policy is tied to cgroups (i.e. see bpf cgroup stuff), so suddenly bpf some stuff affects suid programs that they weren#t affected by before. You might *hope* that there was no bug introduced through the interaction of all that code, but the point I am making is that "struct task" and associated objects in kernel get extended all the time, and suid programs that didn#t expect these additions will be exposed to them, and cannot sanely reset them even if they wanted, since typically developers cannot look into the future (and the cgroup stuff cannot even be reset reasonably at all). Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
