Tobias Hunger

Just use a distribution that uses the init system you want to test by default. The init system is a pretty central piece of infrastructure in todays unix, ditsributions need to invest a lot of effort to make it work well. The default init system always works better than any other options a distribution offers (if they even over options).

These comparisons assume the systems do the same thing, resulting in a comparable system once everything is up and running.

That is just not the case. Systemd does a ton more wrt. security, hardening and reliability. E.g. it has udev integrated and not running “stand-alone” since it tends to lock itself up when it needs to start long-running services in response to HW showing up. Yes that happens rarely but there is nothing you can do about it. Logind locks down permissions to HW way more tightly than the “forks” that have the same problems that the pre-logind system had – and that led to logind getting developed in the first place. Lots of sandboxing options are built into systemd and widely used to run services (I rarely saw any sandboxing elsewhere so far out of the box), measured boot is pretty much a systemd-only thing at this time, … .

I doubt they were the first to built such a system. The idea is pretty obvious after all.

They just are the first to give reporters a guided tour of the system and test accounts to play with.

What you can expect when switching from a system management tool written for Linux to an init tool targetting the least common denominator of general Unix functionality?

Less functionality, less security, less information about the state the system is in, less reliable switching between states and a whole lot less of linux kernel features exposed to your use in convenient ways.

It’s not as if systemd was started to be complicated, the world got complicated. E.g. we used to just create all the device nodes in /dev statically during system installation. Then USB became a thing and supported so many different kinds of devices with thousands of potential ports to connect them to. They would not fit into the device node namespace! So we needed to make device nodes dynamic, which is also convenient.You do not have lots of device nodes that do not exist on your system and you no longer need to change system configuration when you plug your mouse into another port of your system.

Filesystems, security (often linux specific) features, everything is easy more complex (and more dynamic) today than it was when sysv init was a thing. That simple stuff was great when you had to power off your machine to change its available devices. It is less cool when you plug an USB-C cable into your laptop and want to use all the stuff that is now suddenly available.

Why would they need to share ssh keys? Ssh will happily accept dozens of allowed keys.

Why don’t you download the latest release/nightly from github and unpack it somewhere?

Yeap, -O3 is mostly voodoo. Berger has some measurements.

Spoiler: He found your username has a bigger effect on performance than most compiler flags:-)

Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.

There are non-UI applications with similar problems though.

Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.

Usig anything as root is a security risk.

Using any UI application as root is a bigger risk. That’s because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.

So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.

Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.

Ideally you run the UI as a normal user and then use sudo to run individual commands as root.