Lennart Poettering writes:
On Di, 01.02.22 07:14, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) wrote: > Lennart Poettering writes: > > > On Mo, 31.01.22 18:32, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) wrote: > > > > > Lennart Poettering writes: > > > > > > > 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 > > >> > > Ok, so where's the track record of potential security exploits, in similar > > > kinds of tools, that: 1) leverage any of the resources that you mentioned,> > > and 2) but were mitigated, and became ordinary bugs, thanks to the > > > vulnerable code being an isolated daemon process, with a clean > > > environment. > > > > I already described you a vulnerability. And the vulnerabilities in > > I must've missed those descriptions. Is there a reference somewhere that I > can read, which describes them. https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/ I explained a locking DoS there: run privileged code, but with extremly restrictive resource scheduling settings, so that it will acquire privileged resources such as locks (which it can, since it is privileged) but is extremely slow to give up again since it runs awfully slow, due to the extremely restrictive resource settings which are under control of an unpriv caller.
And an isolated process will be capable of rate-limiting itself in this situation any better than a sudo process, which could do the same kind of rate-limiting itself, exactly how?
About the only thing that works to its advantage is that it'll be in a better position to employ rate limiting, by its virtue of being persistent.
But if this is a concern, there's a much better, hybrid approach. The user- initiated executable would be a setuid executable that connects to a filesystem socket, with the permissions adjusted so that only a privileged process can connect to it.
This mitigates resource attacks that establish connections to the persistent daemon, and just hold them open, without doing anything. Depending on the particulars the setuid executable could do its own sanity checks first, before establishing a connection to the persistent daemon, for the next step in the process.
The suid bit itself is not a problem. Much like everything else, it is a useful tool when used correctly. But just because it is used incorrectly, sometimes, doesn't make it bad. And I tend to avoid making an absolute one- size-fits-all, blanket assumption on the order of "X is bad". That's a bit simplistic, and too naive for my taste. I'd rather take a look at each individual situation, on its own merits, and figure out the best solution.
An excellent example would be what happened to OpenSSH. My understanding is that they shuffled off all authentication stuff into a separate daemon that runs with restricted privileges. This is not quite a good analogue for sudo, there is no setuid bit involved here. But this is the right approach: analyze the individual situation, and figure out the best solution. For OpenSSH it seems to be what they picked to do, which makes a lot of sense.
> > sudo from not cleaning up env vars are pretty well documented, too no? > > And they are the same kind: not cleaned up context. > > A basic search finds the most recent sudo exploit was a heap based buffer > overflow in sudo about a year ago. Something that can equally happen in an > isolated process, too, if triggered the same way. CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646, CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629, CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, … These are all env var cleanup issues in su/sudo context.
Picking a few of them, at random: CVE-2006-0151: https://bugzilla.redhat.com/show_bug.cgi?id=139478 # Statement for NVD: ## If an administrator is concerned that users who have been granted sudo # privileges can alter the environment, the existing "env_reset" option should # be used which cleans the whole environment.
Mic drop. CVE-2005-3629: this is initscripts, not sudo, the topic here. CVE-2008-3825: this is PAM, not sudo. CVE-2014-9680: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1191144Looks like env_reset does not reset the TZ variable – that's a bug in that option. Going back to the current thought experiment: what if sudo was a persistent daemon?
Well, this CVE actually proves my point: a persistent daemon would not've made any difference, whatsoever! If all the other sudo drivers were still in play, I'm fairly confident that the same exact bug would've happened, and having an isolated process would not've done anything.
TZ was intentionally excluded from sudo's clean environment. Why's that? Well, I can see sudo's original line of thinking, crystal clear: it would've been rather rude for the spawned subshell to pop up in a different timezone. So, sudo intentionally did not launder TZ for that exact reason.
Well, if the same drivers were in place on the alternate-Earth, where sudo used an isolated daemon, the same drivers would've been present, and the alternate-sudo would've made arrangements for the caller's TZ to be carried to the spawned subshell, overriding the isolated daemon's inherited TZ.
End result: same thing.
Attachment:
pgp6FvnIWY9g5.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
