Sudo and its alternatives

Posted Feb 21, 2024 20:08 UTC (Wed) by bluca (subscriber, #118303)
In reply to: Sudo and its alternatives by oliwer
Parent article: Sudo and its alternatives

Yes - or in other words, a bog-standard run-of-the-mill Linux system as you'll find on the default install of the vast, vast majority of Linux distros.

to post comments

Sudo and its alternatives

Posted Feb 21, 2024 21:39 UTC (Wed) by marcus0x62 (guest, #168201) [Link] (11 responses)

There is a fundamental difference between having those things on a system, and using them in an elaborate scheme (“attack surface”) to arbitrate privileged execution.

Sudo and its alternatives

Posted Feb 21, 2024 22:01 UTC (Wed) by bluca (subscriber, #118303) [Link] (10 responses)

Not really? All those components are already there and widely used together as part of day-to-day system usage. Even the new uid0 is pretty much bells and whistles (and pam integration) on top of systemd-run, which has existed since forever. It was basically an extra ~200 lines of code, pretty much the same size as its manpage, mostly about new command line parameters parsing.

Sudo and its alternatives

Posted Feb 21, 2024 22:56 UTC (Wed) by marcus0x62 (guest, #168201) [Link] (9 responses)

Yes, really. The problem, fundamentally, isn’t the new 200 lines of code. It is the unauditable mess of the rest of the dependencies that are now to be linked in to a program *designed* to allow unprivileged users to escalate privileges.

Sudo and its alternatives

Posted Feb 21, 2024 23:23 UTC (Wed) by bluca (subscriber, #118303) [Link] (8 responses)

> Yes, really. The problem, fundamentally, isn’t the new 200 lines of code. It is the unauditable mess of the rest of the dependencies that are now to be linked in to a program *designed* to allow unprivileged users to escalate privileges.

Polkit has been providing the escalating privileges functionality on Linux for almost 20 years now. It's had its fair share of problems, like any other software, but it is in no way an "unauditable mess", in fact, having recently done some substantial work to improve its robustness and modernize it, its core is pretty well reviewable. It's not in any way worse than larger components such as the kernel, both from the point of view of the size and also for the number of issues that affect it. In fact, I haven't counted but I am willing to bet the Linux kernel gets more high severity CVEs in any given year than polkit did in its entire lifetime.

I have no idea what some rant about screensavers has to do with sudo and its replacements, sorry but you lost me there.

Sudo and its alternatives

Posted Feb 21, 2024 23:57 UTC (Wed) by marcus0x62 (guest, #168201) [Link] (7 responses)

The “rant” was about how an overly complex design for a critical security problem will inevitably lead to vulnerabilities, simply because it gets harder and harder to reason about behavior accurately (or proactively find and eliminate exploitable bugs) as complexity increases. Both the screen locker and sudo/doas/uid0 have the *potential* of failing open - that is to say, to grant more privilege than they should in a failure state.

Sudo and its alternatives

Posted Feb 22, 2024 0:24 UTC (Thu) by bluca (subscriber, #118303) [Link] (6 responses)

> The “rant” was about how an overly complex design for a critical security problem will inevitably lead to vulnerabilities, simply because it gets harder and harder to reason about behavior accurately (or proactively find and eliminate exploitable bugs) as complexity increases.

"Overly complex design" is usually a code word for "some stuff I haven't really looked into but I know I don't like", usually because "back in my day we used to punch holes in cards with a toothpick" or something along those lines.

> Both the screen locker and sudo/doas/uid0 have the *potential* of failing open - that is to say, to grant more privilege than they should in a failure state.

Code for all three of those is available to be cloned, so if you want to provide some proof for that statement, now would be the ideal time to do so.

Sudo and its alternatives

Posted Feb 23, 2024 0:06 UTC (Fri) by marcus0x62 (guest, #168201) [Link] (5 responses)

> Code for all three of those is available to be cloned, so if you want to provide some proof for that statement, now would be the ideal time to do so.

If you honestly believe that there is no potential for these programs to fail open - as sudo has in the past due to exploitable vulnerabilities - or if you simply do not understand what ‘potential’ means, I cannot help you.

Sudo and its alternatives

Posted Feb 23, 2024 0:24 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> as sudo has in the past due to exploitable vulnerabilities

If you look at sudo vulnerabilities ( https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo ), a significant share of them is caused by failing to properly sanitize the environment.

uid0 is much more resilient against these kinds of attacks, because it starts from a known-good state and then drops privileges as needed. Not vice versa.

Is it possible that uid0 missed something? Sure. But it's far less likely.

Sudo and its alternatives

Posted Feb 23, 2024 0:31 UTC (Fri) by bluca (subscriber, #118303) [Link] (3 responses)

Also every single piece of software that was ever written has "potential" for bugs. It's not a useful thing to say, as it's a tautology. The useful thing is, are there any actual bugs? If so, please point them out and we'll fix them

Sudo and its alternatives

Posted Feb 23, 2024 6:35 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

But for some software the "potential" is higher than for others.
E.g. because they are written in unsafe languages or they don't use frameworks like systemd that bring applications into a known consistent startup state.
Just looking at actual bugs is not enough. We have done that for decades and failed miserably.
We have to make bugs harder to happen by design.

Sudo and its alternatives

Posted Feb 23, 2024 18:26 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (1 responses)

> We have to make bugs harder to happen by design.

No, that's the mistake that has been done for a long time and it has not helped, it transforms language bugs into logic bugs because doing the right stuff gets more difficult.

What is needed is to make it easier to do the right thing. Due to this, bugs will be harder.

I would love to see a C standard variant with all UBs clearly defined to safe and intuitive values (mostly what the kernel sets with all its options in fact). *That* would make bugs less likely to happen and more detectable. But others tried in the past and it always ends up in bikeshedding.

Sudo and its alternatives

Posted Feb 25, 2024 21:18 UTC (Sun) by matthias (subscriber, #94967) [Link]

> I would love to see a C standard variant with all UBs clearly defined to safe and intuitive values

What are safe and intuitive values if you do out of bounds access, use after free, data races, etc.? Most of the UB is there because it is actually UB on the hardware level.

Of course there is some UB in C that can be reasonably defined (e.g., signed integer overflow). But most security critical bugs are memory safety errors. And these cannot be defined away. If you want to get rid of these you need ownership tracking (the rust way), garbage collection (the java way) or some other runtime tracking (e.g., only allow reference counted pointers).