This is an old revision of the document!


systemd: Denial or just alternative ways?

We are surely aware about the criticism towards systemd as project. But this article should not only be focussed onto that and be therefore more oriented towards our reasoning for a system beyond using only bloated packages and frameworks. So we could now list for sure many reasons why we stay critical towards the adaption for systemd as basic init-framework, but we want to provide a complete picture.

Introduction

systemd was initially first started back in 2010 as a project to replace the conventional System V init. It was then developed further to be now a “software suite providing an array of system components for GNU/Linux”. And with this short but fitting description there is the first major issue as the project is only aiming towards GNU/Linux as basic and is very much more than a pure init-startup for the operating-system. It provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging.

As Hyperbola is created as pure lightweight system the orientation of systemd is not following the Social Contract to respect modular and lightweight design. This was announced within 2017 in a dedicated news-entry.

With the essential design-decision being just more than only init and management systemd has also included more attack surfaces and further security-issues. To be mentioned there are dereferencing null pointers (Issue 5998), or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number (Issue 6237). Yes, all of them solved or handled in other ways. But a big codebase of a project like systemd is staying also complete intransparent for everyone with not a big amount of time and the reaction of maintainers behind the project are also not that kind of helpful: Communication is a basic element for a good project oriented onto technical emancipation as this is the absolute basic for free culture and free, libre software on its own.

Back and forth: The role of init-systems

There are different approaches followed by the different systems and distributions. Nevertheless the key-role of an init-system is just to start the basic system and initialize the services. Afterwards it is about a supervisor to look behind the services running and removing those crashed (Broken by design: systemd) .

Again the size and the understanding of systemd in a whole is here the major point for issues: Too many components integrated, too many design-flaws within and too less transparency. Hyperbola has chosen for a reason to follow strict the Filesystem Hierarchy Standard. It would not be possible with adaption of systemd and leaving a complete mess for a structured, lightweight operating-system to follow the Unix philosophy. Therefore the conclusion to follow the Init Freedom Campaign.

Points for criticism in detail

We will never address criticism making usage of personal attacks as we conclude neither being unfair nor using false argumentation methods. Besides there are many points to be found making it further a problem to use systemd for any system with lightweight focus.

Breaking promises and immaturity

“After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time” http://article.gmane.org/gmane.linux.hotplug.devel/17392

”…this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. 'Gentoo folks, this is your wakeup call.'“ http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html

“kdbus support is no longer compile-time optional … We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled.” http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html

Stability Promises

“Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future.” http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/

This stability promise was broken as one of their promises is for the export format: This is not true for version 44 of systemd for example!

Scope creep

Absurd Bugs and Responses

Conceptional problems

Scope Creep Leads to Vulnerabilities

Poor design

Ignorance of fundamental operating system concepts

Conclusion for the Hyperbola-project

In the retrospective of all the points listed here Hyperbola has the stance not to accept systemd. It is just the point that there are better alternatives fitting within the approach of a lightweight and stable context for a modern operating-system based on the essentials of the Unix philosophy. It is not a denial as we for sure just see no usecase for a so complex and also bloated piece of software to be used. Our ideal in this: We search for alternative ways as it is an an achievement of civilization that not all need to be the same but treated nevertheless with fairness and therefore in conclusion the same way!

So systemd has to persist the comparison towards other possible init-systems and in that way is for sure too big, too complex and too full with flaws.

Conceptional problems
Scope Creep Leads to Vulnerabilities

* [http://seclists.org/oss-sec/2014/q4/592 systemd-resolved DNS cache poisoning] * To run systemd properly in container a FUSE [https://linuxcontainers.org/lxcfs/introduction/ LXCFS] had to be created, and surely its own share of vulnerabilities: [https://www.cvedetails.com/cve/CVE-2015-1342/ LXCFS before 0.12 does not properly enforce directory escapes] CVSS 4.6 [https://www.cvedetails.com/cve/CVE-2015-1344/ The do_write_pids function in lxcfs.c in LXCFS before 0.12 does not properly check permissions] CVSS 7.2 * [https://latesthackingnews.com/2017/06/29/a-systemd-vulnerability-allows-attackers-hack-linux-machines-via-malicious-dns-response/ A Systemd Vulnerability Allows Attackers Hack Linux Machines via Malicious DNS response]

Poor design

* [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10 Improper argument parsing] * [http://www.freedesktop.org/software/systemd/man/systemd.special.html systemd has a filename that starts with a hyphen!] - This causes all sorts problems as it will usually be interpreted as the start of a command option when used on the command line. You don't even need to specify the filename for it to cause problems as it will affect commands that use globbing. Not to mention that the file in question, “-.slice”, they refer to as the “root slice” which causes confusion as the term “slice” has been used for decades as an alternative way of referring to a [https://en.wikipedia.org/wiki/Slice_(disk) disk partition] yet their usage is completely unrelated. * [https://news.ycombinator.com/item?id=10999335 Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'] See also [https://bbs.archlinux.org/viewtopic.php?id=207549 No POST after rm -rf /] - Lennart's argument for mounting /sys/firmware/efi/efivars as read/write as a default behaviour doesn't hold water. Yes it's true that some tools may need to write to it but those tools are not needed for the general running of a system. efivars should not even be mounted as read-only by default. Those tools that need to write to efivars will generally only be invoked by a system administrator. A competent sysadmin will know how to mount efivars with read/write permissions when they need to to use those tools. The only reason to mount efivars by default is for convenience. This is by no means a good reason. From a security perspective, mounting efivars by default should be strongly discouraged as it breaks the [https://en.wikipedia.org/wiki/Principle_of_least_privilege principle of least privilege]. Lennart goes on to state that [https://github.com/systemd/systemd/issues/2402#issuecomment-177907110 systemd needs to write EFI variables]. This demonstrates yet another example of scope creep and thus poor design. * http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=28640752854 * https://bugzilla.redhat.com/show_bug.cgi?id=1170765 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 “Now you can no longer expect a long running background processes to continue after logging out. For example, you can no longer start a screen or tmux session, log out, and expect to come back to it.” * https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ systemd's predictable NIC names are actually unpredictable…

Ignorance of fundamental operating system concepts

* [http://lists.freedesktop.org/archives/systemd-devel/2015-February/028514.html Lead systemd developer doesn't understand RAID or checksum] * [https://github.com/systemd/systemd/issues/825#issuecomment-127917622 Lead systemd developer doesn't understand su, expects it to do something else and then labels it a “broken concept”] - su isn't supposed to inherit cgroups or audit, those concepts are relatively new and arrived well after the creation of su. TTYs were originally physical devices so of course su is supposed “inherit” the same device otherwise it would be truly broken. Pseudo TTYs emulate real TTYs so their behaviour is obviously expected to be identical. su really is just a simple mechanism that calls setuid(2) in order to switch to another user. If he needs to write a new utility to handle scenarios that su was never designed to handle, no problem, but to label it as a “broken concept” demonstrates a lack of understanding of what su actually is.