Sudo and its alternatives

Posted Feb 23, 2024 0:31 UTC (Fri) by bluca (subscriber, #118303)
In reply to: Sudo and its alternatives by Cyberax
Parent article: Sudo and its alternatives

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