Sudo and its alternatives

Posted Feb 21, 2024 19:43 UTC (Wed) by DimeCadmium (subscriber, #157243)
In reply to: Sudo and its alternatives by bluca
Parent article: Sudo and its alternatives

Ah, right, because setuid is the problem, rather than escalated programs having bugs... Thank you Poettering daddy uwu

Please

Posted Feb 21, 2024 19:48 UTC (Wed) by corbet (editor, #1) [Link] (2 responses)

Look, you can disagree with the approach being taken to this new tool, but please keep your disagreement technical and useful. This kind of comment helps nobody.

Please

Posted Feb 22, 2024 10:44 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] (1 responses)

As an April Fool's suggestion, consider an article wherein systemd wakes up one morning and decides to devour the kernel itself.

No, scratch that: LWN is the great place it is because of the high signal-to-noise ratio, and the aforementioned joke article is best left as a hint to the reader's imagination if inclined.

Please

Posted Feb 24, 2024 0:26 UTC (Sat) by tedd (subscriber, #74183) [Link]

Would you like SystemD erotica? https://www.tiltedwindmillpress.com/product/savaged-by-sy...

Sudo and its alternatives

Posted Feb 21, 2024 19:49 UTC (Wed) by bluca (subscriber, #118303) [Link]

Yes? Setuid binaries are a huge problem, as a good chunk of the article you are replying on mentions itself

Sudo and its alternatives

Posted Feb 21, 2024 19:52 UTC (Wed) by pizza (subscriber, #46) [Link]

> Ah, right, because setuid is the problem, rather than escalated programs having bugs... Thank you Poettering daddy uwu

Yes, setuid is a problem for many environments, which disallow that as a manner of policy. So yes, thank you for providing a tool that many will find useful.

('uid0' also completely separates the runtime environment/session/context from that of the invocation user/session/shell. This eliminates a _lot_ of pain points and data leakage opportunities)

Sudo and its alternatives

Posted Feb 22, 2024 16:33 UTC (Thu) by MarcB (guest, #101804) [Link]

Do you really not see the major difference? With sudo, you are elevating privileges out of a potentially malicious environment.
Even if that is handled correctly, this still requires the kernel to implement the privilege elevation functionality in the first place - something it arguably should stop doing.

With uid0, your are branching off of a pre-existing, clean, privileged environment. No privilege elevation is needed, making whole classes of bugs impossible.

btw, some here argue about the complexity of Polkit and Systemd, but completely ignore the complexity that exists to implement setuid/setgid in the kernel and all the hacks in ld.so, ptrace and other places to make it not obviously insecure. There also are some constraints that would not be necessary if those mechanisms would not exist in the first place. For example, unprivileged chroot would be possible (might still break some software, but the breakage would stay within the initial user account).