Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacement called “run0”.
The developer talks about the weaknesses of sudo, and how it has a large possible attack surface. For example, sudo supports network access, LDAP configurations, other types of plugins, and much more. But most importantly, its SUID binary provides a large attack service according to Lennart:
I personally think that the biggest problem with sudo is the fact it’s a SUID binary though – the big attack surface, the plugins, network access and so on that come after it it just make the key problem worse, but are not in themselves the main issue with sudo. SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended for and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on.
He’s saying that sudo is a Unix concept from many decades ago, and a better privilege escalation system should be in place for 2024 security standards:
So, in my ideal world, we’d have an OS entirely without SUID. Let’s throw out the concept of SUID on the dump of UNIX’ bad ideas. An execution context for privileged code that is half under the control of unprivileged code and that needs careful manual clean-up is just not how security engineering should be done in 2024 anymore.
Lennart also talked about their planned sudo replacement in the upcoming Systemd release and how it works:
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).
One could say, “run0” is closer to behaviour of “ssh” than to “sudo”, in many ways.
Lennart hopes that with the introduction of this new Systemd component, some possible attacks on a Linux system security via sudo like this bug will not be possible in the future, which should enhance the overall security.
He also mentioned that there will be more features in run0 that are not just related to the security backend such as:
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.
The work on Systemd v256 is close to being finished; the project stands at 88% progress for its next release, and could be released in the upcoming weeks. Once released and available in your Linux distribution repositories, you can try the new tool called “run0” as a sudo replacement and test how well it works for you.
It is not yet clear though, which Linux distributions in the future are going to drop sudo for run0. It is still too early to judge, and such change is unexpected to happen any time soon due to backward compatibility. However, distributions like Fedora will definitely be in the lead, judging by previous experiences and stories of adapting new Linux technologies and Systemd components.