systemd isn't safe to run anywhere

Posted on 2020-02-07.
Since the release of systemd in 2010 the project has been getting a continuous and steady stream of new features and added capabilities, and with a code count of more than 1.3 million lines of code, where Lennart Poettering has just added yet another 20.000 new lines of code with the merge of his personal systemd-homed git tree into systemd, and with a continuous open issue counter at about 1.400 issues, where new issues keep popping up, systemd should be considered experimental and not safe to run anywhere.

Even with such meticulous and security minded coders as the developers of OpenBSD, where the source code is subjected to highly scrutinizing code audits, bugs and security issues happens all the time.

Considering how systemd is being developed where the code hasn't even undergone (as far as I know) a single code audit, and the developers keep adding new features instead of focusing on bugs, security, and stability, the project doesn't belong in any GNU/Linux distribution except as in a "testing stage", and any kind of GNU/Linux distribution with systemd is not suited as a production system if security matters.

Even Debian GNU/Linux, with its extended testing in its "testing" and "unstable" releases, before anything goes into the "stable" release, isn't suited for production because systemd still has many open issues and even open bugs dating back all the way to 2015.

Because of the Unix philosofy, originated by Ken Thompson and based upon the experience of the leading developers of the Unix operating system, that emphasizes building simple, short, clear, modular, and extensible code that can be easily maintained, where one program should do one thing well, and if you need a new task managed, you should build afresh rather than complicate old programs by adding new "features", many third party applications such as mail servers, web servers, and lots of other applications, has been completed. As such these applications rarely gets any new features, but instead the developers focus on code correctness, security, and bug fixing.

Adding a simple and single feature that fits very well into an existing code base is one thing, but merging projects with tens of thousands of lines of code is something quite different. That's adding an entire new application in and by itself, yet with systemd still deeply integrated into the so-called "suite of programs".

In his blog post The Biggest Myths , from January 2013, Lennart Poettering tries to argue against calling systemd a "monolith", which is what many people consider it to be. Lennart says:

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

The problem is however, that many of these so-called individual binaries has functionality that simply will not work without other systemd components. If we take a look, just as an example, at the man page for systemd-networkd it clearly states that if you define the option UseDNS as true the DNS servers received from the DHCP server will be used and take precedence over any statically configured ones. This corresponds to the nameserver option in resolv.conf. What it forgets to mention is that this setting (and multiple other settings) doesn't work without systemd-resolved. Other components of systemd is just as tightly integrated.

Some types of applications are very difficult to design and build in accordance with the Unix philosophy, such as modern web browsers, computer games, etc., but systemd isn't such an application. It is violating the Unix philosophy in so many ways that it's difficult to keep track, not because the developers needs to do so, but because they want to do so, they just don't care. And while they are free to not care, and to keep adding more and more features into systemd, it is about time that some of the big GNU/Linux distributions start paying serious attention.

The GNU/Linux many of us know so well, is slowly turning into a disaster, an operating system apocalypse of security issues just waiting to happen. Just because everyone wanted a new init system, but somehow ended up with everything but a new kernel.

If you have any comments or corrections please feel free to email them to me. Also, if you found this content useful consider supporting me on Patreon