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…
6 Likes
They need a catchier name.
E.g.
dammitwouldyoujust reboot
12 Likes
I think it is a marvelous idea, Mr Poettering has such a fantastic track record 
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.
8 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.
7 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 
3 Likes
You could always create a alias
alias dammitwouldyoujust reboot="reboot"
4 Likes
run0… he couldn’t come up with something catchier while he had the chance? 
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.
run0 on the run:
core-testing/systemd 256rc4-1
2 Likes
well i’ll be happy about it if by replacing sudo they also mean replacing things like gksu so we won’t need to install these separately.
Time to think of the alias name.
1 Like
meh, if ain’t broke…Mr. Poettering makes a case that sudo has a “large, possible attack surface” but I’ve never seen this discussion outside of your (@vazicebon ) link. “run0” just does not inspire confidence however 
.
…I am curious about said discussion (sudo=might be unsafe) so will research more.
(no, doas is not an adequate replacement)
1 Like
1 Like