I think these problems are basically negligible because the amount of people trying to "configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it" is negligible. Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of. Even in corporate contexts where the company owns the machine instead of the user, I've only ever seen cases where the use of sudo is unrestricted albeit logged. Where are these organizations where developers or syaadmins are allowed to use sudo but only with white listed commands? I don't doubt that some people are doing this, I just think it's not common.
Replacing the whole of sudo with some weird new thing to better support a niche usecase seems disconnected from reality to me.
That's not what parent means. They are arguing it's not generally used to delegate partial root access to unprivileged users, i.e by adding narrow sudoers rules to allow "some" specific things to be run as root for some users who don't have full root access otherwise.
I tend to agree that 99% or use cases are just a convenient way to gain full root for users with full root access. Configuring sudoers for the former use case has long known to be a bit dangerous, i.e it's easy to get it wrong and create privilege escalation holes.
My last job was at a UK bank. All our *nix systems were configured with a specific whitelist of commands that could be run via sudo.
We found this an enormous pain in the arse when the powers that be decided to deploy ansible everywhere, and found that none of its "become" methods would work if sudo was set up like that.
Its a common finding during pentests, but that's just unconvincing anecdote vs. anecdote. Another argument, besides misconfiguration, is the reduced attack surface by removing the huge complexity of sudo entirely. If your argument is basically that its fine because nobody is using the complexity of sudo, then I don't quite understand what your objection is to removing that complexity. You might need to manually restore some env-vars, whats the big deal?
But I suspect this would just turn into a "doing things differently is bad because its doing things differently" argument, its not a very useful conversation to have.
'systemd-run except with privilege escalation' is a thing I wished for for a long time, needed in production.
Glad they finally made it, too bad it took them so long. (To be honest, it feels like it should have just been part of systemd-run in the first place.)
I mean, systemd-run could do privilege escalation from day one. It's even the default (otherwise overridable by systemd-run -pUser=<user>). I have used systemd-run --shell on countless occasions when I needed a clean root shell without any traces of the current environment.
What is being announced is merely a thin layer of cmdline syntactic sugar over an existing feature, to make it closer to sudo in usage.
> Virtually all users of sudo are using it on their own computer
Nope. If I had to guess, it's in containers, like Docker. And those run in lots of places, and often in places with easy access to company's cloud account, credit card info etc.
Replacing the whole of sudo with some weird new thing to better support a niche usecase seems disconnected from reality to me.