Hacker News Reader

Comment by lupusreal | Hacker News Reader

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.

View on HN

> Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of.

This is not the case at all. The vast vast majority of Linux installs are on servers.

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.

Then I propose letting systemd hijack sudo's usefulness only on server installs.

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.

I had a job once which had a sudo whitelist, but vi was included. !sh and you had root.

Classic case of #CorporateIT applying white paper "rules" and not understanding what they're doing. If I had a nickel...

Exactly, forms were filled in and boxes were checked off.

I also liked one where you could `sudo rpm -i`

Those environments could continue to use sudo. I'm sure Red Hat will support it until long after we all dead.

Not even using "su" as become_method? Granted, it would require the root's password, so it's another tradeoff, but...

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.

So I'm not sure what exactly you were missing?

Currently you have to do `sudo systemd-run --shell` if you want a root shell from a regular user's account.

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

Reply on news.ycombinator.com