Fuck off Poettering. Stop trying to absorb the whole system.
EDIT: apparently systemd absorbing the whole system with it’s nonstandard, monolithic nightmare is a good thing, judging from downvotes. Carry on.
The vast majority of Linux users consider systemd as a good thing because it apparently makes system administration easier. They also don’t agree that systemd is monolithic, because it’s actually designed modular.
But of course there are detractors. The only thing I like about systemd is its declarative service definition and parallel service startup. But if I wanted to run an OS with bloated and inscrutable software (even with the source code), my choice wouldn’t be Linux or Systemd.
I also routinely switch parts of my OS. This is harder with systemd. Although it is modular, the modules are so tightly coupled that it will prevent the replacement of modular components with alternatives. Frankly, I think systemd is killing the innovation in system component development.
because it’s actually designed modular
Oh? Try to use systemd without logind or journald. logind isn’t so bad, but journald was bad enough, that I gave up with systemd.
I use Gentoo with OpenRC. So my position in this matter should be clear. Anyway, check the last paragraph again to see what I think about systemd’s modularity.
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.
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.
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.
I’ve always wondered why we even bother with SUID commands. Why not just log in as root?
On a server, it allows you to track who initiates which root season session. It also greatly minimizes the attack surface from a security perspective to have admin privileged accounts unable to be remotely connected to.
We used to do that a lot, in the 90s and early 2000s. We determined that that’s not a good idea. People even ran DEs under root.
sudo and friends allow you to gain root access while not enabling the root account. If the root account has no credentials then nobody is guessing your password and logging in as an admin.
On a multi-user system it allows for multiple admins without sharing a password. It also allows providing admin access for “some” things but not others.
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.
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.
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.
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.
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.
Lennart’s cancer spreads.
Sounds good. It’s a win win. People that doesn’t like the system d implementation can use doas or keep sudo. I Hate the name though. Run0 is dumb can’t they just steal the name doas
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.
At this point I looks to replace systemd with vim. Anything better than systemd mess
