On Mo, 31.01.22 07:46, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) wrote: > > > 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". See the discussion around seccomp and NNP. i.e. a new kernel facility was added precisely to ensure that seccomp cannot be used to run code that is intended to be run privileged – under security policies in control by an unprivileged user. i.e. if you can take certain privs away from code that expects to have them you might be able to trigger vulnerable codepaths that the developer didn't expect you to be able to trigger. But anyway, don't focus so much in cgroups here. There are plenty other props these days that sudo doesn#t clean up. consider this for example: plenty of priv code takes file locks or similar, that unpriv code is not supposed to be able to take. If it could, it could DoS priv code and thta should not be possible. Given that sudo doesn't clean up "nice" levels, I am pretty sure it's easy to construct an exploit from that: i.e. issue "nice -n 19 sudo …" on some priv program that takes a lock, and at the same time hammer the system with a bunch of programs that want the CPU. Now, the priv program takes the lock, but given the nice level of 19 will not be scheduled anymore for a long long time, because your other programs monopolize the CPU an run at nice level 0 like all other user code. So now the priv lock is taken and remains so, and all other priv code that wants it will block for basically forever and you trigger all that from your unpriv user account. You can make this even worse I guess if you throw IO and CPU scheduler settings into the mix, and mask off all CPUs in the affinity mask. Suddenly the priv code has no chance to ever get the lock again because the resources it might theoretically get access too became soo ridiculously artificially scarce that it never runs anymore... This entire problem set doesn't exist if you run your services nicely isolated, because if a client gets no chance to muck with priv code's affinity mask, nice level, priorities, cgroup, … it cannot trigger these vulnerabilities. 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
