Lennart Poettering writes:
On Di, 01.02.22 09:01, Sam Varshavchik (mrsam(a)courier-mta.com)
wrote:
> 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.
Rate limiting is a generic term. It doesn't only mean "how often
something happens". Anyway:
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.
The relevant part would be "limiting". Something that repeatedly does what's
described here could be described as a rate-limiting problem, but that's a
minor issue. More importantly: it seems to me that an isolated daemon which
acquires the same resource, on behalf of a low-priority, unprivileged
process, will also end up block a higher-priority unprivileged process from
getting that resource, in the same manner. Not sure how this would address
priority inversion.
Perhaps one can say that an isolated process might factor this in, then
juggle the competing resource requests based on the requesters' priorities.
But that sounds like a lot of work for me, and more complicated work for a
privileged process to do. More opportunities for bugs to happen. Bugs in
privileged processes are bad.
But I want to closely focus on the exact "shared resource" part here, and
examine the actual requirements. I really don't like discussing things in
this kind of a general manner. Practical details matter to me. I would like
to dig into the specific, actual instance here, on its own merits.
Is this shared resource really needed to be used in the manner that makes it
possible for priority inversion to happen; or can it be used differently,
somehow, in a way to avoids it. The questions to answer should be a little
bit more sophisticated than "how to remove an setuid bit from a program,
this'll fix all the problems".
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...)
Maybe it should, maybe this is a good idea. Maybe it makes sense for a shell
with elevated privileges to start with a lowered priority by default, and
root would be able to elevate its privileges if needed. I don't play root
very often, I have no opinion, but this is an unrelated topic.
But if I was convinced that it was a good idea then this is what I would do
already: contacting the sudo-stewards and submitting a patch. It's worth a
shot, and that's what I would do, if it bugged me. A few years ago, because
of a crazy reason, I thought that adding a few bits to libxcb would be a
useful thing to do, and I did exactly that. And they agreed! So, rather
than wondering, why doesn't X do Y, how about: take the bull by the horns
and see what happens?
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.
I would agree: having openssh being a suid program is …not recommended.
Anyway, I understand your love suid and sudo.
I love suid and sudo no more, no less, and exactly the same as I love my
screwdriver. I'm married to neither. Both are just tools. Both can be used,
by people, correctly. Both can be used also, by people, incorrectly. But it
makes no sense to use that as a reason for replacing screwdrivers with
wrenches.
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.
I never claimed that others are not allowed to have different opinions, or
there's something wrong with them if they do. I have to admit that a long
time ago I might've believed something like that. But I'm older now and I
recognize that others will have different opinions. I'm not affiliated with
sudo, in any way, and have no skin in the game. If they choose to update
sudo to work in the described way, more power to them and we'll see how that
works out. If Fedora decides to get sudo replaced by some alternative that
works this way, we'll see how well that works out too, when it happens.