The outrage is that the solution is to suck the feature into an already massive project built to replace initd and has absorbed several other services (syslog, logind, crond), creating dependencies along the way.

systemd will be superceded, like pulseaudio, because it has an awful design. It’ll just be a lot more work for distros to replace because of all the other services it’s absorbed. Hopefully by then Poettering will have retired and stopped inflicting his software in people. The problem isn’t his initial offerings; those are rather good and solve a problem well. Good enough that distros adopt it. It’s just that he can’t resist feature envy and bloat, and once a distro has a dependency on his solution, the bloat comes along and it’s more work to switch away than just let the bloat take over.

Edit: “superseded?” Where were you when I needed you, autocorrect?

mesa and linux is also “uber projects” i think in certains canes you can’t run away from them, systemd is the same, but for privilegiated processes that need to be well integrated for security reasons

I just want Sudo registered to a hardware key. No sudo for you unless you plug in your key.

Let’s get back to the old hacker movies where burglary was involved.

Why would they remake core utils?

the whole security model of sudo makes no sense

I think that is a bit strong. Sure, you aren’t gaining much protection if you just allow sudo -su root but there are a lot of valid use cases.

1. Logging.
2. A bit of an “explicit” check to keep you from doing something stupid without thinking.
3. You can configure sudo to only allow specific commands from different users. (Maybe a trusted friend should have permission to reboot your Minecraft server but nothing else)

The only problem I found was, that it has no real alternative to sudoedit

it is. arguing attack surface with systemd IMO is a losing battle though.

It seems Poettering is convinced doas, while decreasing attack surface, depends on SUID binary implementation which is a concern in its own right. Poettering is trying to eliminate that dependency in his `run0’ implementation to reduce the attack surface even further.

The relevant excerpt from the long chain of posts from Poettering’s mastodon.social account is copied below:

… led various people to revisit the problem and come up with alternatives: most prominently there’s probably OpenBSD’s sudo replacement called “doas”. While it greatly simplifies the tool and removes much of the attack surface, it doesn’t change one key thing: it’s still a SUID binary.

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. 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.

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.

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. 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 be authorized by priv servers.

By isolating the contexts and the resources of client and target we remove some other classes of attacks…

… entirely, for example this stuff:

https://ruderich.org/simon/notes/su-sudo-from-root-tty-hijacking

But enough about all that security blabla. The tool is also a lot more fun to use than sudo.

Read the rest where he explains run0’s use and functionality beyond the design logic.

The main problem with sudo and doas is that they are not developed by Lennart. Seriously.

Some scripts or programs assume sudo by default. It’s a stupid thing but also annoying.

systemd is the opposite of Wayland.

Wayland took a monolithic system (Xorg) and broke it apart (Wayland, compositors) to try to make a smaller, cleaner codebase with separation of concerns.

systemd took an already separated system of discrete, interchangeable components and, like a katamari, rolls along absorbing services and clumping them together into one giant monolithic system. It started out as a replacement for init.d, and then decided it needed to absorb syslog, and then crond, and then mounting /home, and now it wants sudo.

systemd is the “see:” in the definition of “feature envy.” Of you look up the “the Unix philosophy”, systemd is the exact opposite; people who oppose systemd don’t do it for no reason; they oppose it because it violates every tenant of the Unix philosophy.

I would guess the Wayland people would be aghast at the comparison.

That doesn’t seem to clear up anything other than indicating that the fork was motivated by wanting to do things differently for the sake of being able to do things differently.

Which is fine, I do this often enough. But I don’t expect to get a lot of others to follow suit on that basis alone.

You’ve got Artix if you’re a Arch fan too

You were so preoccupied wondering what asinine comment you could make that you never bothered to read the article and learn the reasons that they should.