Lennart Poettering, main developer of systemd, has announced run0, a systemd-based replacement for the well-known sudo command that fixes many of he inherent issues with the widely used tool to gain temporary elevated privileges. There are various problems with sudo, which basically come down to that it’s a large SUID binary, meaning it consists of privileged code that unprivileged users can run from their own context. This makes sudo a fairly large attack surface, and why OpenBSD uses doas instead; while doas suffers from the same main problem, it’s much smaller and reduces the attack surface considerably.
SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended 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. A few of these settings the kernel is nice enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that.
Lennart Poettering
Poettering wants to address this problem, and has come up with run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new 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. Except that it doesn’t bother with encryption or cryptographic authentication, key management and stuff, but instead relies on the kernel’s local identification mechanisms.
run0 doesn’t implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients authenticate against priv servers.
Lennart Poettering
This approach addresses a whole slew of attack vectors on sudo, and it comes with fun additional features like being able to give your terminal a different background tint when using it, or displaying a little red dot in the terminal window title to further indicate you’re using elevated privileges. It will ship as part of the upcoming release of systemd 256.
SUID was not only for running as “root”, but allowed multi-user systems to share tools for private use.
For example, you could write your own “/home/sukru/post_note”, and allow other students that use the system to have limited access to your directory with a hatch.
I guess we are moving away from old style UNIX philosophy to modern “Linux-ism” one inch at a time.
sukru,
Agreed. For better or worse, this is what’s happening.
Ironically Pottering’s run0 works very similarly to the init system I wrote nearly two decades ago for my distro, which my distro called “rund” for “run daemon”. Instead of forking privileged processes from the current context, there was a protocol to instruct pid 0 to launch a new process tree. My idea was to be able to support adhoc job execution on a read only file system without requiring config files in order to create/launch jobs.
Being able to launch adhoc jobs from scripts and/or command line and have them be manipulated as normal jobs was useful in the readonly squashfs environments I was dealing with.
Alfman,
Did now know you built your own distro. But then, it was very common to see Linux from Scratch, or Gentoo back then. In any case, that is a good achievement.
sukru,
Yeah, I was younger, less experienced, and happier back then. I felt I could do anything, joining the workforced killed my soul
To “switch user” require elevated privs. So, while I understand the “logic” and the “need” (perhaps unlike Lennart “there is no use case” Poettering), the fact is, elevation is required. But no, if LP’s goal is to fundamentally destroy (which he does btw), then this won’t succeed. Systemd has been pretty busy breaking lot of things (if, for whatever reason, you chose to implement, like their very limited view of mounting for example).
As LP always says “you don’t have to do this” (and then it gets rammed down our throats… sure, we can build our own distros from scratch… I guess that’s always an option. Waiting for the project to take over stuff like C or “x86”, so that we can build our languages from scratch and CPUs, etc See, you do have a choice!)
For me, looking from a high vantage point, it seems like most Linux distributions are becoming “systemd” distributions.
Systemd took over networking, name resolution, X11, and later Wayland setup, multi-user switching, remote connections, and whatnot.
To be honest, I have not been an active “system level” user of Linux in a while. However every now and then I try something, and realize systemd made it either impossible, or very hard to achieve.
How does that astronaut meme go? “Always have been”.
It’s darkly amusing to me how far the most popular Linux-based OSes have strayed from their UNIX-like roots, yet still are considered UNIX-like by the community at large. The combination of the GNU userland, Linux kernel, Wayland display server, and systemd init/service supervisor/bootloader/dns resolver/syslogger/ntp replacement/device manager/login manager/mount manager/system bus manager/home directory (mis)manager/networking manager/more stuff I can’t remember…all of this makes Linux based OSes very much un-UNIX-like.
Linux distros that keep it simple and actually UNIX-like are a dying breed, sadly. Slackware, the oldest distro still in active development, is feeling more anachronistic every day. Void is amazing and my first choice for a Linux based OS, but its community is tiny; fiercely dedicated and friendly, but tiny nonetheless. Alpine is great but hyper-focused on use in containers and VMs. Devuan is, sadly, a parody of itself these days and continuously broken. Crux is phenomenal but nearly impossible for a newbie to pick up and run with, it’s barely easier than LFS. Ditto for KISS Linux, its philosophy is sound but you have to be a seasoned Linux user to properly understand and maintain it yourself.
Like it or not, Linux on the desktop will soon be a vaguely UNIX-like kernel running at the core of an incoherent mound of bleeding edge, test it in production, throw shit at the wall and see what sticks garbage. It’s no longer a bazaar, it’s a mob of angry bees who all hate each other but all hate their users even more.
I’m very happily running SystemD-free on MX linux.
UNIX doesn’t really mean anything, unless it means POSIX standard support.
MacOS, Solaris, AIX, and HP-UX are all very different and incompatible. Yet, they all claim UNIX heritage. Looking at each one, they are probably not UNIX anymore. They aren’t the lean OS from the ’80s which ran on expensive RISC workstations and servers.
There is a lot of complexity in modern computing.
This is especially true on the desktop side, and many of the technologies pointed out are explicitly for the complexity of the desktop environment. Servers are much easier, and they could be paried down. Breaking off desktop into it’s own project would probably be good.
Making Linux it’s own userland, instead of using the GNU userland, to create a Linux base would be helpful as well.
Also, Gentoo was left out, and it’s the most classically Unix-like distro from my perspective.
Linux has never been UNIX. It’s was always supposed to be a vaguely UNIX-like kernel coupled with the GNU tools.
Linux has traditionally been much more user friendly then regular UNIX systems. Solaris was a much rougher experience, by comparison.
Flatland_Spider,
Linux wasn’t UNIX in terms of a trademark, but Linus did actually set out to create a UNIX clone using GNU tools. It’s only once Linux displaced UNIX that Linux started becoming less UNIX-like.
Morgan,
Slackware was my first disto, and I used it as much as I could. At one point, tools like “checkinstall” were helpful managing packages not provided by the base, however it became really cumbersome, and I had to switch to others (Gentoo first, then Fedora and CentOS for a long while).
Multi-user *nix systems are an obscure niche these days.
It’s a little late. That horse escaped from the barn 20 years ago.
Linux is Unix.
Unix is Linux.
There is no Unix only Linux.
Linux is not Unix. UNIX doesn’t exist anymore. It’s a trademark of the OpenGroup, and it’s only used to signify the vendor has paid for the conformance test. Meanwhile, Linux is the de facto standard for Unix like operating systems.
Whichever bumper sticker is preferred.
Solaris was the canonical UNIX OS, and it was moving towards a more integrated and centralized approach a decade ago. Apple is the largest UNIX vendor in the world with a decidedly new-style UNIX OS.
There are the BSDs for anyone who would like an old-style UNIX-like OS. Especially OpenBSD and NetBSD.
Amen.
Some people are focusing on Lennart because he is recognizable and easily “hateable”, and are making him the Only Reason behind the move away from traditional Unix approach to something more modern… Well, during my life I have worked with Unixes from all over the technical landscape, from AIX to Ultrix, Solaris and Irix, and all of them were treading away from the “official common denominator” called Unix. So, systemd infrastructure is not a surprise, and is almost welcomed (almost, because I would have made different choices :-D)
Also, I’d like to see more projects like systemd. There is aurea (https://aurae.io/) originaly designed by the late Kris Nóva, and on the old stuff list there is still DJB’s daemontools. But I’d like more
aurea looks interesting.
There is also GNU Shepard, the default init for Guix. Service files are written in Guile Scheme. It’s not exactly like systemd, or the systemd ecosystem, but it is an init and supervisor.
https://www.gnu.org/software/shepherd/
Didn’t that guy leave Red Hat and now work for Microsoft? Can he instead contribute to Windows and leave Linux alone?
Microsoft has their own Linux distro to run on Azure.
Now that he works for Microsoft, we has essentially reinvented Windows “runas” but for Linux. Go away, Lennart, go away!
No, definitively no. If only runo could be used instead of runas, I’d be really happy. But runas and runo are very differently, feature wise.
It is a strange optic that large suid binary is bad, but huge binary running as root, pid 1 even, and spawning arbitrary shells is perfectly safe.
mbq,
Both are methods of achieving privilege escalation. There are risks executing binaries under a potentially malicious environment. Obviously these can be mitigated by sanitizing the environment so that ideally nothing gets passed in. But the problem with suid fork/exec is that the environment gets inherited by default. Sanitizing it is left as an exercise for sysadmins & application developers. Obviously starting a new clean environment would help mitigate human errors though.
To be honest, I think the best solution would be to enforce a new environment for all SUID binaries such that every SUID binary could assume a clean environment by default. This would also have the advantage of maintaining true PPID relationships in the process list (breaking the process hierarchy is a shortcoming of the systemd/run0 proposal). As usual though the problem with changing the way old APIs work is that there’s tons of old code that relies on current behavior. There is a lot of pressure keep the original behavior around no matter the risks.
This puts the onus on sysadmins/developers to consistently get it right. Ideally we always would, but shellshock might serve as a reminder of how even egregious security oversights can make their way into production systems.
https://metalkey.github.io/shellshock-explained–exploitation-tutorial.html
Probably a better idea would be to do away with SUID/SGID entirely and replace them with a combination of role-based access control and capability transfers between processes, although doing that on Linux would be difficult.
andreww591,
Yeah, I’ve always hated the POSIX permission bits, especially coming from windows. There are of course the new access control lists, but they are poorly supported in general and when I tried to do away with POSIX permissions in my distro I discovered several caveats such that I’d need a hybrid approach using both the bits and ACL, which was frustrating as heck. Personally I feel windows has the better permission system, although it doesn’t do sandboxing well so I’d say there’s room for improvement all around.
Did you experiment with adding MAC, like SELinux or AppArmor?
Being able to automatically set the group ownership on new files with SGID is rather helpful, and it would be nice if SUID did the same thing.
The part where the files are run in the context of the set user or group is not helpful.
Of course, the scope of access can also be limited with a MAC mechanism like SELinux, and it frequently is.
Well I get that, my point is that run0 motivation is flawed but claiming that properly sanitizing environment in a suid code is practically impossible, but not mentioning the challenges with dbus and polkit. E.g. I could say that writing a bug-less pile of polkit XML & JS (!) is practically impossible, so simple authorization checks of sudo are superior.
In fact, docker is a non-suid program that can run arbitrary things as root (via daemon run as root, as run0) with very sketchy access checking, so the run0 model can be completely botched.
The risks are known, and it’s one of the holes in the Unix permission model. It’s not too long ago that X.org was running as root by default, and a rootless X.org was a big accomplishment.
Hopefully this allows superuser permissions to be doled out to accounts in a fine grained fashion instead of having to carefully craft kludgy sudo rules.
Systemd is not huge.
Size of sudo: 269400 bytes
Size of systemd: 96720 bytes
Carewolf
I wouldn’t put too much into binary sizes, these days even tiny projects can end up with large binaries with tons of boilerplate crap getting linked in. But I checked the sizes on debian and my results were very different to yours…
When you count up all the additional shared objects that get linked in by ldd, your looking at quite a large footprint for systemd, much larger that you’d expect for what it does.
Most of the problems with sudo have already been solved by OpenBSD’s implementation of “doas.”
I don’t think he’s wrong in his criticisms of sudo/doas. But I’m not sure if his solution is the right one. Polkit instead of /etc/sudoers? I get the point of that, but I’m not a huge fan of Polkit’s configuration. From my limited experience with it, it seems much more complex than /etc/sudoers for simple cases. Would love to hear a comparison between them for someone who has more experiences as a real sysadmin than I do. But maybe the solution is to make polkit the one true solution for unprivileged processes to speak with privileged ones, to be better and easier to configure. I’ve not had to do that, so I’m woefully ignorant of it for the most part.
Switching to polkit would make things easier for desktops. The polkit enabled GUI stuff is much nicer then the GUI stuff which relies on sudo. The same for CLI tools as well.
My DD account has sudo privs, and with the amount of time I spend running sudo, it’s more of a speed bump then a security measure.
Oh, I understand the need for something like polkit that does exactly what it does, how it does it. I just don’t like the syntax/format of the config files themselves. /etc/sudoers is pretty simple to understand pretty quickly. That doesn’t mean its a better solution.
Fair enough. Config languages are generally pretty terrible, for one reason or another.
They are rather brief, and their brevity has its own problems, like dealing with command arguments.
Sudo is good at what it does, but it is running into limitations due to the demands of modern environments.
Mixed feelings about this. I generally approve of systemd and how it’s unified and improved Linux init and services management, but Poettering has a record of bringing things under the systemd umbrella that he does not have the skillset to write or maintain – see for instance the history of bugs in systemd-resolvd and systemd-timesyncd. That he’s now bringing in a sudo replacement, i.e. another security-critical piece with highly specific requirements, does not fill me with confidence.
I hope this is for config management like Ansible or Puppet, and it tackles the problem of them needing accounts or services which become secondary root accounts.
There are problems with the Unix-style permissions model, mostly that it’s all or nothing in regards to superuser access. sudo can be setup to be fine grained, but I haven’t seen that.
Then there are problems with sudo, like not being able to map an account to a corresponding admin account which has a separate password from the regular account which is invoking sudo. sudo can be setup to ask for the password for the target account or root, but not something per account.
Flatland_Spider,
It’s just acting as a proxy for child spawning, it’s not going to fix anything in terms of fine grained access, although I agree with you that unix has never done that very well.
Technically capabilities are supposed to offer an alternative to root’s all or nothing model…
https://blog.ploetzli.ch/2014/understanding-linux-capabilities/
However they are still not fine grained enough, are poorly supported in general and are hard to use effectively. Unfortunately what’s happening with these older operating systems is that we end up tacking on security after the fact, but this is much harder and less effective than starting with a secure sandbox model up front and then opening it up with explicit permissions.
That’s disappointing.
Who would have though an OS designed to be single user and whose first job was running single user on ATT telecom switches would have a bad permissions model?
Yeah, I think that OS was Multics. LOL
You know, “everything should be in a container” keeps coming up. Too bad starting containerized services is still rather bad, and people haven’t even started on making interactive accounts containerized..
Whatever the merits of this, if Lennart Poettering is involved, it will doubtless be implemented and foisted on people in the most high handed, arrogant and abrasive manner imaginable.
I posted the following somewhere else nearly 2 years ago:
It’s possible he keeps working on systemd from Microsoft. Embrace, extend, extinguish.
My long term prediction is Microsoft will adopt the Linux kernel and some other aspects e.g. systemd as it is a glue layer.
systemd is cancer.
If this becomes standard, it’s going to ruin that XKCD.
“run0 make me a sandwich” just doesn’t have the same ring to it.