Lennart Poettering writes:
On Mo, 31.01.22 06:28, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) 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.
I would like to see some hard data here: how many exploits, historically, leveraged all those ancillary, inherited process metadata that would not've worked if the targeted process had this ideal environment.
An argument is being advanced that having an isolated process, with a clean environment, would be an effective mitigation strategy that prevents exploitable vulnerabilities.
This should be demonstrable with prior art. Of course, it's fair to include the other side of the coin: documentation of incidents where there was no exploit clearly because of the isolated process's environment blocking any exploitation of a bug. Both, I think would be fair to cite as a authoritative data.
So, where's the prior art?
> 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.
And when the cgroups did not exist, when everyone lives in the same sandbox, something would stop the same, exact, exploitable program from exploiting whatever it coulf exploit as part of the cgroup, and with no other differences? Continuing with Star Trek quotes: as Mr. Spock would say "this is highly illogical".
It's difficult to talk in generalities but, presumably, prior to cgroups, the other actor that's involved in this theoretical exploit might've used some other access control mechanism, or authentication mechanism.
With the same exploitable program, it will either be able to leverage the other actor, before cgroups, with its alternative access control mechanism, or not. The prior security model was, presumably scrapped in favor of cgroups. That, as I understand, is the described scenario here.
So, the grand total that I see here: if the prior security model also didn't stop the same exploit being leveraged, then cgroups made no difference. If it did, switching to cgroups made it worse.
And in both cases, the issue is the nature of the actual bug in the exploitable program, and not anything else. Suid is just a scapegoat.
Attachment:
pgpOjpiRXnqMn.pgp
Description: PGP 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
