joe curlee

systemd has very recently become front and center in heated online debates within Linux communities due to California's AB-1043, Colorado's proposed SB26-051, and Brazil's Law No. 15,211/2025—all of which are laws aimed at collecting a user's date of birth at the OS level so that it can be provided to app stores under the guise of "protecting children." Most people see this as a massive privacy violation, and in the United States, a direct violation of the First Amendment.

However, systemd has been a controversial part of the Linux operating system since it was first introduced in 2010 by Lennart Poettering and Kay Sievers. Traditional Linux init systems followed a philosophy of doing one specific task well. systemd, by contrast, is a massive suite of tightly coupled daemons that manage everything from network configurations (systemd-networkd) and user sessions (logind) to device management (udevd) and logging (journald). These components communicate heavily via D-Bus interfaces.

This encompassing architecture inherently expands the potential attack surface of the distros that use it. Because systemd runs as PID 1 and its peripheral daemons often run with root privileges, a vulnerability in a secondary service can have catastrophic system-wide implications.

Known Exploits

CVE-2018-16865 and CVE-2018-16866

In December 2011, approximately twenty months after systemd was first released in the spring of 2010, a vulnerability later identified as CVE-2018-16865 was introduced. This vulnerability was a critical memory corruption Stack Clash flaw in systemd-journald. When systemd-journald received a massive number of log entries through its journal socket, it attempted to allocate space for them on the stack. Crucially, journald did not properly limit the size of these allocations.

By sending a carefully crafted stream of data, an attacker could force the stack to grow so large that it clashed with (and overwrote) other regions of memory, such as the heap or another thread's stack. By controlling what data was written during this clash, an attacker could hijack the execution flow of the journald process. Successfully exploiting this flaw allowed a standard, unprivileged user to gain a root shell.

As detailed by Qualys Research Labs, this exploit went undetected for SEVEN YEARS and affected almost every major Linux distribution. Every systemd Linux distro was vulnerable to this bug with only a few exceptions. While primarily a local attack, the vulnerability could theoretically be triggered remotely if a system used systemd-journal-remote to collect logs from other machines, significantly increasing the blast radius.

In June 2015, another exploit known as CVE-2018-16866 was introduced and went undetected for 3.5 years. It allowed an attacker to read process memory data, which could be used to bypass security protections like Address Space Layout Randomization (ASLR).

Both CVE-2018-16865 and CVE-2018-16866 lived in the core logging daemon, journald. Because journald runs with such high permissions, gaining access to it essentially unlocks the rest of the system for an attacker to exploit as they please.

Privacy Concerns

The core privacy complication with journald lies in its design as an append-only, binary log store. The architecture fundamentally conflicts with granular data deletion requests (such as the GDPR Right to Erasure). If a specific log entry contains Personally Identifiable Information (PII), there is no native tooling to excise that single line. Admins must delete the entire log blob or attempt complex export-filter-import workarounds to remove the offending data.

When an application crashes, the OS generates a core dump (a literal snapshot of the application's working memory at the exact moment it fails). The memory dump contains whatever raw data was being processed. Depending on the application, this could mean session tokens, unencrypted passwords, environment variables, private communications, credit card numbers, or anything else that was in the application's memory at the time of the crash.

Crash reporting tools like Ubuntu's Apport interface with these dumps and send the logs to Canonical (the corporation responsible for Ubuntu). It is important to clarify that Apport is a distro-level tool and not a systemd component—it is Ubuntu-specific and does not ship with Debian or most other distributions. However, it interfaces directly with journald and the /var/crash directory, creating a pipeline between systemd's logging infrastructure and Canonical's servers. Apport is designed to ask for explicit user consent before transmitting the data; however, Canonical stores these logs indefinitely and complies with law enforcement by turning the logs over upon request. Although these raw logs are first accessed by a "small trusted security team" at Canonical, they are often uploaded to public bug trackers, which has historically led to PII being leaked to the public web. It should be noted that switching away from systemd alone does not eliminate this risk if you remain on Ubuntu; the Apport daemon operates independently of the init system. Switching away from Ubuntu entirely does.

Additionally, malicious applications running on the local system can attempt to scrape journald logs or /var/crash directories to harvest PII left behind by the crashed processes of other applications.

The Origin of systemd

The Alleged Reasons for Introducing systemd

systemd was first introduced by Lennart Poettering and Kay Sievers in 2010, who were both working for Red Hat at the time. They claimed sysvinit (the traditional Linux architecture) was antiquated and slow. It relied on the serial execution of shell scripts, started services one at a time, and made it difficult to manage complex service relationships. They introduced systemd to solve these "problems," establish a unified way of handling services across distros, and cleanly terminate child services to leave fewer leftover processes.

Controversy and Fallout

Upon introducing the new architecture, they faced immediate pushback. The core argument was that an init system should only start and monitor processes—not manage logs, hostnames, networks, and user logins. Fedora 15 became the first major distro to adopt systemd. In 2014, Debian decided to switch to systemd, which led to a massive internal conflict, several high-profile resignations, and the eventual fork of Debian into a systemd-free alternative called Devuan.

The Architects

Lennart Poettering is the primary architect and public face of systemd. He was born in Guatemala City, but grew up in Rio de Janeiro, Brazil, and Hamburg, Germany. He is a German citizen. He worked for Red Hat from 2008 to 2022 and joined Microsoft in 2022 to work on Linux-related projects. In 2026, he co-founded a startup called Amutable, which focuses on "integrity verification" and "deterministic trust" for Linux systems.

Kay Sievers was a key co-developer of systemd and the primary maintainer of udev (the device manager) before it was merged into the systemd project. He grew up in East Germany and currently resides in Berlin. Sievers was famously banned from submitting code to the Linux kernel for a period by Linus Torvalds due to a dispute over how systemd handled kernel debug messages.

So, to recap: systemd was born at Red Hat, a company now owned by IBM. It was created by two engineers—one who grew up in Brazil and now runs a company directly adjacent to OS-level identity verification, and another who was banned from the Linux kernel by Linus Torvalds himself. Ultimately, the monolithic systemd architecture makes it functionally easier for corporate and state entities to implement centralized logging, tracking, and deanonymization across the Linux ecosystem.

Unplugging from systemd

What can you do to escape this privacy and security nightmare? The answer is clear: switch to a distro that does not implement systemd. As mentioned, one of those distros, Devuan, was born out of the controversy surrounding the introduction of systemd. Devuan is well maintained and still uses sysvint, but there are other choices available.

• privacy
• security
• linux
• systemd
• journald