On Di, 01.02.22 09:01, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) wrote: > > 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? "Rate-limiting"? Not sure what "rate-limiting" has to do with any of this. If priv code runs with extremely low prio, and acquires a shared resource, that other priv code might wait for that isn't low prio, then you have a classic prio inversion issue. because the higher prio code will be slowed down to the level of the low prio process, which can be used to DoS things. prio inversion issues are well known and more or less just bugs. But they become a security issue once unpriv code has control of the prios of priv code and can bring the system to a standstill hence. Which is the case here with sudo. (i.e. the fact that sudo dosn't at least do a simple setpriority(PRIO_PROCESS, 0, 0); is beyond me...) > 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. So, apparently I am beyond terrible in explaining the issue, given your unrelated responses. But I don't think I am going to waste more time on this. If my explanations weren't useful now I doubt I can improve them, so let's end this specific branch of the thread here. > 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. Yeah, OpenSSH split up its stuff into multiple processes that talk to each other via IPC and where privs are never acquired, but only lost. it's the perfect example of how to actually do things well, and *not* using setuid because it's a broken design. > 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=1191144 These are all issues where insufficent process context cleanup (specifically env var cleanup) made setuid transitions exploitable. It's always the same issue. Anyway, I understand your love suid and sudo. But please accept that some people, me being one of them, think the concept is a very bad idea. Some others have voiced their takes already on this mailing list. Let's end this branch of the thread here, it's really pointless from my PoV I just keep repeating myself. 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
