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 monolithic 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. We search for alternative ways!

Absurd Bugs and Responses

* [https://bugs.freedesktop.org/show_bug.cgi?id=74589 Unchecked null pointer dereferencing in PID 1 not considered a serious issue] - <i>“To make this work we'd need a patch, as nobody of us tests this.”</i>, <i>“I will not work on this”</i> - Systemd <b>requires</b> cgroups and segfaults if there is no cgroups support. * [http://www.phoronix.com/scan.php?page=news_item&px=MTYwMzg Screen locking issues (including a security issue) with gnome-shell] - remained unfixed for over a year] * [http://soylentnews.org/article.pl?sid=14/12/21/1343258 PID 1 segfaulting on upgrade; journalctl usability issue] - bug report still marked as “NEW” * [https://lists.debian.org/debian-user/2015/02/msg00010.html “Tried to boot my laptop from a cafe…”] * [https://bugzilla.opensuse.org/show_bug.cgi?id=918226 systemd segfaults after updating from 208-23.3 to 208-28.1] * [https://github.com/systemd/systemd/issues/2402 Mount efivarfs read-only] - Doing rm -rf / bricks your computer * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171 Unable to shutdown] * [https://bugs.freedesktop.org/show_bug.cgi?id=61191 journald eats up CPU] * [https://bugs.freedesktop.org/show_bug.cgi?id=64116 Corrupted binary logs] * [https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet How to Crash Systemd in One Tweet] (works as any user, not just root) and [https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d response] and [https://www.agwa.name/blog/post/systemd_is_not_magic_security_dust rebuttal] * [http://www.openwall.com/lists/oss-security/2017/01/24/4 Systemd v228 local root exploit] * [https://github.com/systemd/systemd/issues/5644 tmpfiles: R! /dir/.* destroys root] See also [https://www.preining.info/blog/2017/04/systemd-again/ Systemd again (or how to obliterate your system)], Poettering's response: <i>“I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but “rm -rf /foo/.*” will work the exact same way, no?”</i> (Hint: no.) * [https://github.com/systemd/systemd/issues/6237 systemd can't handle the process previlege that belongs to user name startswith number, such as 0day] Poettering: “not a bug, a feature” * [https://serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime systemd Using 4GB RAM After 18 Days of Uptime]

Conceptional problems

* [http://soylentnews.org/article.pl?sid=14/12/21/0145243 Systemd Prevents the Skipping of fsck while Booting] - still unresolved * [http://soylentnews.org/article.pl?sid=14/12/21/1554227 Systemd Disables the Linux Magic SysRq Key] - closed as “NOTABUG” * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 Please do not default to using Google nameservers] - Debian package maintainer refuses to acknowledge the privacy leak and closed the bug. * [https://github.com/systemd/systemd/issues/437 timeX.google.com provide non standard time] - Horrible default behaviour but Lennart tries to shift the blame on distros because “systemd is not a product”. * [https://bugs.freedesktop.org/show_bug.cgi?id=76935 Do not parse “debug” command line parameter] - [https://lkml.org/lkml/2014/4/2/415 Response on LKML] Response: [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c2 That is the expected current behaviour, “debug” can cause “too many” messages to be useful anymore if things are broken.] * [https://github.com/systemd/systemd/issues/2447 journal ip anonymization] - It's very difficult to use systemd/journal on a privacy aware system or infrastructure. * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 systemd kill background processes after user logs out] - Poettering's answer: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XW7V5A3RAWYCACU2ZMPA27ARRLIZUI37/ In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.] * [http://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is-broken.html systemd-resolved is broken] - doing DNS resolve wrong, with the [https://github.com/systemd/systemd/issues/5755 usual attitude towards feedback] Debunking the myth of unit files being significantly shorter than scripts used by all other init systems: [https://jdebp.eu/FGA/run-scripts-and-service-units-side-by-side.html A side-by-side look at run scripts and service units]

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.