This just sounds like a bad idea, a solution in search of a problem. Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code. It’s also a very fundamental piece of the system that you want to always work, even (especially!) when other things get borked. The brief description of run0 already has too many potential points of failure.
I mostly agree with your write-up here. That said, I do think that systemd does want to eliminate SUID. I also think they want to absorb most of the low level system plumbing.
There are other applications that use suid (like newuidmap). And there are programs that use capabilities (like ping). I’m pretty sure that this logic will be used to justify assimilating those applications too. But I’m sure that the crowd will cheer them on as if they did something revolutionary.
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?
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.
Nobody is using all of sudo’s features because those features are for different use cases. Case in point, LDAP support. At home, pretty much nobody uses it. But on the job, where there are tens to hundreds of machines that someone might need, and they’re all hooked into LDAP for centralized authentication management, it makes sense to have that built into sudo. Same with Kerberos support - at home, forget it, but in a campus environment where Kerberos (and possibly AFS) are part of the network, it makes sense.
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
This just sounds like a bad idea, a solution in search of a problem. Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code. It’s also a very fundamental piece of the system that you want to always work, even (especially!) when other things get borked. The brief description of run0 already has too many potential points of failure.
deleted by creator
I mostly agree with your write-up here. That said, I do think that systemd does want to eliminate SUID. I also think they want to absorb most of the low level system plumbing.
deleted by creator
There are other applications that use suid (like
newuidmap). And there are programs that use capabilities (likeping). I’m pretty sure that this logic will be used to justify assimilating those applications too. But I’m sure that the crowd will cheer them on as if they did something revolutionary.deleted by creator
Have to trust the code ? doas for OpenBSD was created because of issues with sudo.
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
suwhen you’re really stuck.sudois 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.doasis 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.systemdis 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 withrun0? What specific part of its implementation do you seem to have a problem with? It’s just a symlink tosystemd-run, which is already very well tested and has been around for a long time. It’s also far simpler thansudo, 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.
Nobody is using all of sudo’s features because those features are for different use cases. Case in point, LDAP support. At home, pretty much nobody uses it. But on the job, where there are tens to hundreds of machines that someone might need, and they’re all hooked into LDAP for centralized authentication management, it makes sense to have that built into sudo. Same with Kerberos support - at home, forget it, but in a campus environment where Kerberos (and possibly AFS) are part of the network, it makes sense.
Some people would disagree to this.
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:
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
As far as I know, the exploit you are referring to, wasn’t actually a vulnerability. https://youtu.be/awkoa_WxFIg?feature=shared&t=659 Although feel free to correct me on that one
Here is an alternative Piped link(s):
https://piped.video/awkoa_WxFIg?feature=shared&t=659
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
good bot