The thing with this is: its just a symlink to the systemd-run binary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debian systemd package includes systemd-run.

I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is makepkg that should never be executed as root, but does internally call some things with elevated privileges (mostly pacman to install and remove packages). Currently it checks for sudo and if not falls back to su, but maybe it might be worth considering changing su for run0 if its guaranteed to be there.

doas is quite popular in the BSD world, and was ported to Linux a few years ago (via the OpenDoas project).

For starters, it’s is a lot smaller than sudo - under 2k lines of code vs sudo’s 132k - this makes it lot more easier to audit and maintain, and technically less likely to have vulnerabilities.

Another security advantage is that doas doesn’t pass on the environment variables by default (you’d have to explicitly declare the ones you want to pass, which you can do so in the config).

The config is also a lot simpler, and doesn’t force you to use visudo - which never made sense to me, visudo should’ve just generated the actual config, instead of checking it after the fact. Kinda like how grubby or grub2-mkconfig works. But no need for that complexity with doas.

Eg, the most basic doas config could just have one line in the file: permit: wheel. Maybe have another line for programs you want to run without a password, like permit nopass dexter cmd pacman.

Essentially functionally stripped sudo, smaller in size than sudo. See also Pottering’s thoughts about the ecosystem

Thanks for taking the time to explain. I was trying to get my head around on how this works but could not understand much of it. A lot of people here are very much against systemd in all senses, but this sounds like a better approach. Even if it not done as systemd, makes more sense than checking files and getting elevated privileges for a scope and use guardrails everywhere

Idk for the network stack, but for homed, I think it’s because it is up to the DEs to support it. As part of the Sovereign tech fund, GNOME is implementing support for it! I think this will be a great step forward for Linux desktop security when it lands

user-password based encryption of the home directory, so the password is required to unlock it (no admin access)

That seems like a very niche feature given that it is only relevant if the admin isn’t the same person as the user but the admin would have to set it up and condemn themselves to hearing endless whining from users who lose their files when they forgot their password.

More like over baked but still only half done.

That’s how I feel as well. IMO it’s ridiculous that Fedora wants to remove xorg completely from the repos in the next version.

Sure, but that doesn’t change the fact that Wayland compositors are forced to be inflexible monoliths that need to be so tightly integrated into a DE that they can’t be replaced.

Edit: I’ve just learned that it’s not forced, but that every compositor used by popular DEs is an inflexible monolith by choice.

In xorg the server, wm, and compositor all do their own thing and can be replaced trivially. It took me like 5 minutes to replace xfwm4 with i3, and that included the research.

I think what they meant is that there are people that think: “Wayland is too fragmented, there should be 1 ‘Wayland Compositor’ and the rest should be window managers”

X11 is a protocol too. Xorg is the binary you are talking about

They’re also all shit and dysfunctional as hell. Xorg forever. Systemd good too.

Wayland is set of protocols.

Oh my god! It’s like hearing the same on hold greeting again and again. WE KNOW!

But gnu utils work on BSD and others, while Systemd is Linux only.

Not really, because you’re now going to make it do more, i.e. incorporate the functionality of sudo and expose it to user input. So unless you can prove that the newly written code is somehow inherently more secure than sudo’s existing code, the attack surface is exactly the same.

You didn’t follow the XZ-utils story ? The malicious actor worked for years on that XZ backdoor that targeted the fact that some Linux distributions were modifying their openssh package to enable systemd notifications.

I’d be willing to bet it’s people fearing another xz-like situation

took me about an hour to get started with artix originally, and maybe a couple more to really familiarize myself with the init. As for practicallity, it’s been a large improvement for me.

Probably not much time, a lot of packages come with init scripts anyway, and they’re pretty trivial to write if not.

You can certainly argue it’s a philosophical choice, I’d say it’s more down to recognising the many poor architectural choices in systemd, rubbing agaist its many pain points and misfeatures and being alarmed at the size of the attack surface it exposes. I understand there is an effort underway to reduce the size and complexity of the main shared library to help address the last point, but just the fact that is necessary shows the scope of the problem.

Easy with sudo apt remove --purge --allow-remove-essential --auto-remove systemd:

:-D Time to go outside.

A lot of debs add services to systemd, do those just skip that part?

That comment was brought to you by an AI LLM. No one actually took the time to write that.

Either that, or it’s a joke.

Yes, because it’s easier to take care of octogenarians than people who might actually put up a fight to having their laptop batteries replaced with a pipe bomb.

Debian in many ways isn’t as slow-moving as people think.

For example, they moved to Wayland by default (for Gnome anyway) in 2019. A number of well-known distros likely won’t have that until 2025/2026 or beyond.

1. The attack surface is there either way, this is just functionality repackaged that existed already before (systemd-run, which is calling into PID1)
2. all compression libraries (actually most libraries at this point) are dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)

As Microsoft and Poettering intended.

Lmao yeah exactly

I don’t understand how this is any improvement over pkexec

That has the same problem as sudo: the SUID bit is set for it.

The fact that run0 uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone can systemctl status, but systemctl reboot needs to be in the wheel group) which is why its generally used within systemd already. And it wouldn’t surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.

I’m unclear from the documentation, does pkexec work under non-GUI contexts?

You know what’s nice? Being able to sit down at any Linux distro and being able to set up and configure services without Googling how to use that particular distro’s init system.

Those hacked together system-specific bash scripts were shit. Having a standard way of creating, starting, ensuring restarts,and logging services is so much better.

You can still get all the plain text logs you like.