Sudo and its alternatives

Posted Feb 23, 2024 0:06 UTC (Fri) by marcus0x62 (guest, #168201)
In reply to: Sudo and its alternatives by bluca
Parent article: Sudo and its alternatives

> 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).