A replacement for sudo

Hello,

Looks like the future systemd release (v256) will provide a more secure replacement for sudo called run0.

9 Likes

It will probably take the over the world just like doas has in the Linux space…

5 Likes

They need a catchier name.
E.g.

dammitwouldyoujust reboot
9 Likes

I think it is a marvelous idea, Mr Poettering has such a fantastic track record :rofl: What could go wrong…

3 Likes

The tool is also a lot more fun to use than sudo. For example, by default, it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven’t given up the privileges yet, and marks the output of all commands that ran with privileges appropriately. It also inserts a red dot (unicode ftw) in the window title while you operate with privileges, and drops it afterwards.

7 Likes

I will need to look into more but on the surface it sounds pretty interesting to me.

In addition to not being setuid, it sounds like it will inherently not allow some of the questionable ways you can use alternative solutions.

5 Likes

That’s actually pretty nice, not gonna lie. It adds some eye candy and eye candy is, mostly, nice. I wonder if this can’t be added to sudo, though.

5 Likes

With systemd v256 we are going one step towards this. There’s a new tool in systemd, called “run0”. Or actually, it’s not a new tool, it’s actually the long-existing tool “systemd-run”, but when invoked under the “run0” name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY.

Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that’s an explicit exception, i.e. allowlist rather than denylist).

Sounds pretty interesting.

3 Likes

1000% increase in folks searching how to create an alias.

6 Likes

It sounds like it might be a good option for servers, or other systems where additional security hardening is desired.

For the desktop, sudo seems kind of baked in; it may not be easy to convince folks to switch, even if it were a better option for this reason or that. In the case of Arch Linux specifically, undoubtedly it will remain a matter of user choice (after all, Arch does not ship with sudo installed either).

I think that’s a good point: if an alias to sudo was set up it is likely a lot of folks wouldn’t even notice.

1 Like

RunO ?

Shoudn’t that be DunnO :upside_down_face:

3 Likes

You could always create a alias

alias dammitwouldyoujust reboot="reboot"

:rofl:

4 Likes

run0… he couldn’t come up with something catchier while he had the chance? :clown_face: I vote for Dunn0

3 Likes

Makes you wonder why opendoas was not enough?

opendoas is basically the same as sudo at a high level. It is a different codebase with different options but it more or less works the same. From a security perspective, it is different code, but not a fundamentally different approach so it has most of the same challenges.

This is something completely different.