I never understood the hate, tbh. A lot of users don’t even care if Sysd is used, as long as it works. So… Since the majority of distros use it… I think it works enough.

Basically, the SUID bit makes a program get the permissions of the owner when executed. If you set /bin/bash as SUID, suddenly every bash shell would be a root shell, kind of. Processes on Linux have a real user ID, an effective user ID, and also a saved user ID that can be used to temporarily drop privileges and gain them back again later.

So tools like sudo and doas use this mechanism to temporarily become root, then run checks to make sure you’re allowed to use sudo, then run your command. But that process is still in your user’s session and process group, and you’re still its real user ID. If anything goes wrong between sudo being root and checking permissions, that can lead to a root shell when you weren’t supposed to, and you have a root exploit. Sudo is entirely responsible for cleaning the environment before launching the child process so that it’s safe.

Run0/systemd-run acts more like an API client. The client, running as your user, asks systemd to create a process and give you its inputs and outputs, which then creates it on your behalf on a clean process tree completely separate from your user session’s process tree and group. The client never ever gets permissions, never has to check for the permissions, it’s systemd that does over D-Bus through PolKit which are both isolated and unprivileged services. So there’s no dangerous code running anywhere to exploit to gain privileges. And it makes run0 very non-special and boring in the process, it really does practically nothing. Want to make your own in Python? You can, safely and quite easily. Any app can easily integrate sudo functionnality fairly safely, and it’ll even trigger the DE’s elevated permission prompt, which is a separate process so you can grant sudo access to an app without it being able to know about your password.

Run0 takes care of interpreting what you want to do, D-Bus passes the message around, PolKit adds its stamp of approval to it, systemd takes care of spawning of the process and only the spawning of the process. Every bit does its job in isolation from the others so it’s hard to exploit.

SUID stands for Set User ID. An SUID binary is a file that is always run with the UID of the owner user (almost always root). Note that this does not require that the user running them has root permissions, the UID is always changed. For instance, the ping command needs to set up network sockets, which requires root permissions, but is also often used by non-root users to check their network connections. Instead of having to sudo ping, any normal user is able to just run ping, as it uses SUID to run as the root user. sudo and doas also require functions that necessitate them running as root, and so if you can find out how to exploit these commands to run some arbitrary code without having to authenticate (since authentication happens after the binary has started running), there is a potential for vulnerabilities. Specifically, there is the privilege escalation, which is one of the most severe types of vulnerabilities.

run0 starts using systemd-run, which does not use SUID. Instead, it runs with the permissions of the current user, and then authenticates to the root user after the binary has already started to run. systemd-run contacts polkit for authentication, and if it succeeds, it creates a root PTY (pseudo-terminal/virtual terminal), and sends information between your session and the root PTY. So this means that in order to achieve privilege escalation with run0 as root, you have to actually authenticate first, removing the “before authentication” attack surface of sudo and doas.

TL;DR SUID binaries will always run as the owner (usually root), even before any form of authentication. run0 will start with the permissions of the current user, and then authenticate before running anything with root permissions.

Suid is a bit set on executables that results in them being run as the user that owns the file without needing a password, for example, passwd as root.

Run0 ignores this bit

Hear me out, breathes in, “Linux defender”

I’d just like to interject for a moment. What you’re referring to as Linux, is in fact, SystemD/Linux, or as I’ve recently taken to calling it, SystemD plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning SystemD system made useful by the SystemD corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the SystemD system every day, without realizing it. Through a peculiar turn of events, the version of SystemD which is widely used today is often called Linux, and many of its users are not aware that it is basically the SystemD system, developed by the SystemD Project.

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the SystemD operating system: the whole system is basically SystemD with Linux added, or SystemD/Linux. All the so-called Linux distributions are really distributions of SystemD/Linux!

So we’ll have to say GNU/Linux/SystemD soon?

Systemd does a lot of things that could probably be separate projects, but run0 is an example of something that benefits from being a part of systemd. It ties directly into the existing service manager to spawn new processes.

It does make sense for me to have this functionality in systemd the way they want to go about doing this.

You can create aliases

I’ll just use an alias; sudo has been around for to long for me to change it and not be stressed about it.

Well, since doas has a Linux implementation, stealing that name would cause lots of issues to users who already use it or want to use doas instead of run0. This will be a default part of systemd; not a new package. The reason it’s called run0 is because it’s just a symbolic link to systemd-run, and instead of executing as an SUID binary, like sudo or doas, it runs using the current user’s UID.

The article says it works by messaging systemd to run the process as the given user, rather than being a SUID binary. So it wouldn’t work without systemd.

Most systems ship with systemd

That wasn’t the “sudo”, MS just named something else “sudo”.

Alias sudo=run0

sudo provides sudoedit or sudo -e which allows me to use vim with my user configuration btw

deleted by creator

sudo is a setuid binary, but it’s a fairly simple program

Sudo is actually fairly huge and complex. Alternatives like really or doas or su are absolutely tiny by comparison.

Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code.

Have to trust the code ? doas for OpenBSD was created because of issues with sudo.

Talking with deraadt and millert, however, I wasn’t quite alone. There were some concerns that sudo was too big, running too much code in a privileged process. And there was also pressure to enable even more options, because the feature set shipped in base wasn’t big enough.

I’ve actually ran into some of those problems. If you run sudo su --login someuser, it’s still part of your user’s process group and session. With run0 that would actually give you a shell equivalent to as if you logged in locally, and manage user units, all the PAM modules.

systemd-run can do a lot of stuff, basically anything you can possibly do in a systemd unit, which is basically every property you can set on a process. Processor affinity, memory limits, cgroups, capabilities, NUMA node binding, namespaces, everything.

I’m not sure I would adopt run0 as my goto since if D-Bus is hosed you’re really locked out and stuck. But it’s got its uses, and it’s just a symlink, it’s basically free so its existence is kBs of bloat at most. There’s always good ol su when you’re really stuck.

sudo is not a fairly simple program. Last I checked, it had ~177k lines of code. It provides functionality far beyond what is needed of an average user. doas is a simpler alternative (also using SUID) at ~3k lines of code. It comes from OpenBSD. There is absolutely a problem when it comes to SUID binaries. If you can find a way to exploit the permissions given at the start of the SUID binary before user authentication occurs (since the UID is set before the binary runs), you have yourself a full privilege escalation vulnerability. systemd is very well integrated with the distros that use it, being the first process to run after the kernel is initialized. There will never be a point at which systemd is not functioning, but the rest of your system is perfectly fine. It is an absolutely necessary part of the system (assuming your distro uses it), and if it goes down, you have to restart your system. As such, I don’t see any validity to the statement “you want to always work, even (especially!) when other things get borked”. What exactly do you see as being an issue with run0? What specific part of its implementation do you seem to have a problem with? It’s just a symlink to systemd-run, which is already very well tested and has been around for a long time. It’s also far simpler than sudo, and removes the attack surface of running an SUID binary of its size. What “points of failure” do you see here, exactly?

Have you seen the average sudoers file? It is not simple in the slightest

I have 0 knowledge of these things, but I do know that people always comment that sudo is bloated, that nobody is truly using everything that sudo can do, only one basic command.

sudo is a setuid binary, but it’s a fairly simple program

Some people would disagree to this.

The brief description of run0 already has too many potential points of failure.

If the “listener” is PID1, which will run the privileged command, in theory, it would be quite bullet proof (in a working system PID1 is always there). But since this is systemd, PID1 is much more than that and much more complex. On the other hand spawning another daemon from PID1 to be the “listener” makes it, perhaps, even more complicated. You’d have to make sure the listener is always running and have some process supervisor there to watch if it exits… and maybe even a watchdog polling it to make sure it isn’t frozen.

So my conclusion is the same as yours:

a solution in search of a problem

We already have a working solution. Have a well written SUID program. I’ve been using doas for some years now. It’s simple enough that I trust it.

it took less than a day for someone to break run0 totally open, so basically, you have a choice between a well tested/debugged sudo and this new thing which may eventually mature

Read the article.

It does something different and doesn’t ask to replace sudo everywhere. You brainless trashtalkers can’t even read an article before you judge.