On Di, 01.02.22 09:01, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> 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