Lennart Poettering writes:
On Di, 01.02.22 09:01, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) 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.
Attachment:
pgp9H1ppbMNDq.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
