Der Hauptentwickler und Maintainer von Systemd, Lennart Poettering. Quelle: CC-BY-SA-3.0 /Wikimedia Commons

Systemd übernimmt heute in nahezu allen Distributionen als zentrale Komponente den Boot-Prozess, die Diensteüberwachung und das Ressourcenmanagement. Über Sinn und Zweck mancher Features und des ganzen Systems sprachen wir mit dem Systemd-Maintainer Lennart Poettering.

Der Hauptentwickler und Maintainer von Systemd, Lennart Poettering. Quelle: CC-BY-SA-3.0 /Wikimedia Commons

Linux-Magazin: Was steht denn noch auf der Wunschliste für die nächste Zeit?

Lennart Poettering: An Systemd arbeiten viele Leute mit verschiedenen Interessen. Ich persönlich habe großes Interesse daran, Linux schlicht und einfach noch sicherer zu machen, und damit meine ich klassisches, generisches Distributions-Linux.

Es schmerzt ein bisschen, dass andere Betriebssysteme wie MacOS oder Windows die User-Nutzdaten momentan besser schützen, als wir das unter Linux gemeinhin mit unseren Home-Verzeichnissen tun. Auch die nicht traditionellen Linux-Systeme wie ChromeOS oder Android sind im Allgemeinen viel besser abgesichert als klassische Linux-Distributionen, weil sie etwa Offline-Modifikationen des Systems erkennen und verhindern. Auch Anwendungen laufen darauf standardmäßig in relativ sicheren Sandboxes. Unter klassischem Linux gibt es das alles bisher nicht wirklich. Es existieren zwar entsprechende Projekte, aber den “Mainstream” der Linux-Distributionen hat bisher nur wenig davon erreicht.

Genau an dieser Stelle hoffe ich, die Situation etwas zu verbessern. Die grundsätzliche Infrastruktur bringen die meisten Distributionen zwar durchaus mit, aber es fehlt an Integration, am Verbinden der verschiedenen Subsysteme, um sie tatsächlich nützlich zu machen. Genau darauf zielt etwa die Unterstützung für TPM2/PKCS#11/FIDO2 ab, die ich bereits erwähnt habe: Die Subsysteme für die jeweiligen Techniken existieren schon lange, aber nur wenige Spezialisten setzen sie tatsächlich zusammen ein, weil die dafür notwendige Integration mit dem Rest des Betriebssystems nie stattfand oder nicht abgeschlossen wurde. Hier sehe ich Systemd als das Projekt, das genau das gut übernehmen kann: feststellen, wohin die Reise gehen soll, und dann die dafür notwendigen Subsysteme ineinander integrieren. Beispielsweise passt es genau in dieses Schema, Festplattenverschlüsselung an TPM2/PKCS#11/FIDO2 zu binden. Aber es gibt auf diesem Gebiet noch viel mehr zu tun.

So setzen unter Linux zwar viele Benutzer – womöglich sogar die meisten – Festplattenverschlüsselung ein, aber typischerweise schützt das Eintippen des Festplattenpassworts den Programmcode nicht besonders gut. Einem Evil-Maid-Angriff – also einer Offline-Attacke, bei der jemand einfach den Boot-Code des anzugreifenden Systems austauscht – ist man deshalb hilflos ausgesetzt. Es gibt keine Chance zu erkennen, ob das Cryptsetup-Binary, dem man sein Passwort übergibt, wirklich das ist, dem man vertraut, oder nicht vielleicht ein untergeschobenes, das das Password umgehend an einen Angreifer weiterschickt.

Andere Betriebssysteme schlagen sich da deutlich besser, auch Linux-basierte. Ich möchte, dass wir mit den generischen Linux-Distributionen dorthin aufschließen, damit die Daten auf unseren Laptops in jeder Hinsicht mindestens genauso sicher bleiben wie etwa auf einem ChromeOS-System. Es ist geradezu peinlich, dass das noch nicht der Fall ist. Insbesondere in Zeiten von Pegasus und ähnlichen systematischen Sicherheitsbedrohungen müssen wir besser werden. Ich denke, Systemd kann und sollte da eine gewisse Rolle spielen, um generische Distributionen sicherer zu machen als bisher: Mehr TPM2, endlich sinnvolles Secure Boot, mehr Sandboxing, mehr Verschlüsselung, mehr Integrity – und alles, ohne dem Admin wirklich mehr Wissen abzuverlangen.

Ein verwandtes Thema in diesem Kontext ist auch Rust: Früher oder später sollten wir von C weg. Es ist einfach zu schwierig, die Sprache korrekt zu verwenden, und selbst die besten Entwickler machen ständig Fehler. Rust ist wohl die erste Sprache, die die Chance hat, C auf breiter Front zu ersetzen. Für Systemd heißt dass, das wir uns überlegen müssen, wie wir als Entwickler den Übergang bewältigen. Wir wollen da aber nicht den Pionier spielen, sondern eher warten, dass andere Projekte die drängendsten Probleme für uns lösen, bevor wir selbst den Sprung machen. Für uns ist eine Programmiersprache schließlich nur Werkzeug und nicht Sinn.

Linux-Magazin: Eines der Ziele von Systemd war ja eine Beschleunigung, aber auch Vereinheitlichung der Abläufe beim Booten. Dieses Ziel kann heute, wo die meisten Distributionen auf Systemd setzen, als erreicht gelten. Geschah dies aber nicht auch um den Preis, dass im Fall von sicherheitsrelevanten Fehlern sofort eine viel größere Anzahl von Systemen betroffen ist, als das bei größerer Diversität der Fall wäre?

Lennart Poettering: Beschleunigung war nie primäres Ziel der Systemd-Entwicklung, sondern schlicht ein Nebeneffekt der Anstrengung, den Boot-Vorgang einigermaßen zeitgemäß zu implementieren. Das haben wir auch immer wieder betont. Wir versuchen stets, die Balance zu finden, um ein verwaltbares, modulares System zu haben und dabei einigermaßen geradlinig und rasch zu booten. Im Zweifel haben wir uns aber immer für Korrektheit und Managebarkeit entschieden.

Ein Beispiel: Wir arbeiten viel mit kleinen Dateien in Drop-in-Verzeichnissen, etwa mit Unit-Dateien, die in »/usr/lib/systemd/system/*« liegen. Das unterstützt Modularität, sodass Paketmanager einfach und elegant Komponenten zum Betriebssystem hinzufügen und daraus entfernen können. Für die Boot-Geschwindigkeit ist das eher von Nachteil: Packten wir die Dienstebeschreibungen in eine einzige große Datei anstatt in viele kleine, ließen sie sich mit ziemlicher Sicherheit um ein Vielfaches schneller lesen – aber modular wäre dann gar nichts mehr. Letzteres ist uns aber wichtiger als schlichte Geschwindigkeit beim Booten, deshalb arbeiten wir trotzdem mit solchen Drop-in-Dateien.

Ich halte es für keine gute Idee, vermeintliche Geschwindigkeitsvorteile gegen Sicherheitsgewinne durch mehr Init-System-Alternativen aufzurechnen – das hat nichts miteinander zu tun. Ja, es wäre gut, wenn es überzeugende Linux-Init-System-Alternativen zu Systemd gäbe: Konkurrenz belebt das Geschäft, Monokultur ist nicht ideal. Aber ich glaube immer noch, dass das Allerbeste für mehr Computersicherheit bessere technische Sicherheitskonzepte sind. Mehr Sandboxing, Lockdown, Integrity-Checks und so weiter. Man tut der generellen Computersicherheit sicher keinen Gefallen, wenn man mehrere Init-Systeme weiterpflegt, die keinerlei Sicherheitskonzepte bieten. Wenn wir aber Systemd Sicherheitsfunktionen geben, die dann breit zum Einsatz kommen, ist das unterm Strich deutlich mehr wert.

Um es anders auszudrücken: Ich finde es viel interessanter, eine Klasse von Angriffen komplett unmöglich zu machen, als darauf zu hoffen, dass “nur” eine Hälfte der Linux-Welt dafür verwundbar ist, weil die andere ein etwas anderes System einsetzt. Zudem gibt es ja durchaus interessante Konkurrenz, die die Sicherheit von Computer-Systemen vorantreibt, wie etwa die genannten ChromeOS, Android, Windows, MacOS und so weiter. Für uns ist das höchst relevante Inspiration.

Und eines möchte ich noch geraderücken: Bisher sieht Systemd eigentlich sehr gut aus, wenn es um die Themen Codequalität und Vulnerabilities geht. Wir haben deutlich weniger CVEs oder Ähnliches (zugegebenermaßen eine mediokre Metrik) als andere Projekte mit ähnlich vielen Codezeilen. Man sollte auch nicht vergessen, dass Projekte wie etwa Wpa_supplicant mehr Codezeilen auf die Waage bringen als Systemd (auch der Kernel hat ein Vielfaches davon). Mit allen Komponenten, die Systemd so mitbringt, ist das Init-System also nicht gerade die Komponente, um die man sich primär Sorgen machen muss. Die Angriffsoberfläche des Wifi-Stacks oder des Kernels fällt weitaus größer aus, eine Monokultur dort bereitet also sicherlich größere Probleme.

Linux-Magazin: Ursprünglich war Systemd ja als Ersatz für das SysVinit-System gedacht. Inzwischen verwaltet es jedoch alle möglichen Ressourcen, bis hin zu einem eigenen Out-of-Memory-Killer. Nun hatte ja 2018 schon Facebook einen selbst entwickelten OOMd als Konkurrenz zur Implementation im Kernel vorgestellt. Was macht die Systemd-Version besser als die beiden Vorgänger?

Lennart Poettering: Der in Systemd integrierte Systemd-oomd-Dienst wurde von Facebook-Entwicklern programmiert, er ist eine vereinfachte Weiterentwicklung des alten getrennten OOMd.

Systemd verwaltet nun einmal Systemdienste, das ist seine ureigenste Aufgabe. Zwei Facetten dieser Verwaltung bilden Lifecycle Management und Resource Control, das heißt das korrekte, saubere Hoch- und Herunterfahren von Diensten zu den richtigen Zeitpunkten und das Zuweisen von Ressourcen und deren Grenzen. Ein OOM-Dienst greift in genau diese beiden Teile direkt ein: Abhängig von individuell konfigurierbaren Parametern fährt es bei Bedarf Services herunter. Das funktioniert am besten, wenn sich der OOM-Dienst und Systemd einig sind, was zu tun ist. Deswegen integrieren wir Konzepte: So kann Systemd-oomd das System analysieren und aktiv werden; der Systemd-Dienstemanager weiß darüber Bescheid und informiert den Administrator korrekt.

Zudem gilt hier: Wir fügen immer dann Komponenten in Systemd ein, wenn wir annehmen, dass der Dienst letztendlich einem erheblichen Großteil der Anwender nutzt. Das dürfte auch bei Systemd-oomd so sein. Um verfügbare Ressourcen so gut wie möglich unter Last zu nutzen, braucht man einen Dienst wie OOMd: Anders als etwa der OOM-Killer im Kernel hat er das ganze System im Auge. Er versucht alles, um Ressourcenknappheit und dadurch erzeugte Latenzen möglichst lokal zu behandeln und nicht etwa das ganze System zu treffen. Das benötigt man, um dicke Server möglichst vollständig auszulasten, aber auch, um in Embedded-Systemen mit wenig Ressourcen ein Maximum zu erreichen. Das hilft auch auf dem Desktop: Zum ersten Mal kann man mit »make -j« auf dem falschen Build-Tree nicht mehr seinen Laptop einfrieren.

Linux-Magazin: Wie passt Systemd in eine Welt, in der Applikationen immer öfter gar nicht mehr direkt aus dem Betriebssystem heraus gestartet werden, sondern in Form von Containern?

Lennart Poettering: Auch dabei benötigt man ein darunterliegendes Betriebssystem. Beim Container-Konzept geht es (neben anderen Aspekten) primär um Isolation vom Host-Betriebssystem. Eine weitgehende Isolation vom Host-Betriebssystem ist aber bei vielen Anwendungen weder hilfreich noch möglich. Einen Dienst, der extensiv auf Hardware zugreift, kann man nur mit Hacks und über Umwege im Container laufen lassen.

Container sind ohne Frage sehr nützlich – aber eben eher für Payloads als für Systemkomponenten. Für Letztere braucht man eben Infrastruktur, wie Systemd sie zur Verfügung stellt. Das Sandboxing, das Systemd für Systemdienste anbietet, ist letztlich von Container-Konzepten inspiriert. Es trägt aber der Tatsache Rechnung, dass nun einmal für Systemdienste die komplette Isolation (etwa ein eigener kompletter Verzeichnisbaum) eher hinderlich ist. Daher ermöglicht es ein viel modulareres Sandboxing, das versucht, Integration zu erlauben, aber die Angriffsoberfläche für Hacks trotzdem soweit wie möglich zu minimieren.

Linux-Magazin: Was unterscheidet via Nspawnd gestartete Container von den Portable Services?

Lennart Poettering: Systemd-nspawn ist ein vielseitiges Tool, und das gilt auch für Portable Services. Wo das eine mehr Sinn ergibt als das andere, ist nicht immer klar definiert. Grundsätzlich würde ich aber sagen: Bei Systemd-nspawn geht es darum, ein bisschen wie leichtgewichtige VMs zu arbeiten. Zum Beispiel lässt sich in Nspawn ohne Aufwand ein mehr oder weniger vollständiges Linux booten, fast wie in einer VM. Bei Portable Services geht es eher darum, individuelle Systemdienste etwas portierbarer zu machen, also es zu erleichtern, relativ integrierte Systemdienste zwischen Maschinen zu verschieben.

Man könnte auch sagen, dass das erste Programm, das als Nutzlast in einer VM läuft, der Betriebssystem-Kernel ist. In einem Nspawn-Container ist es stattdessen ein Betriebssystem-Init-System, in einem Portable Service dagegen das Hauptprogramm eines Diensts. Letzteres ähnelt vielleicht einem Docker-Container, aber diese laufen eher isoliert vom Host-Betriebssystem, Portable Services jedoch nicht so sehr.

Linux-Magazin: Für das Container-Management haben sich auf breiter Front Kubernetes samt seiner Ableger wie OpenShift durchgesetzt. Welche Nische kann da Systemd-nspawn bedienen?

Lennart Poettering: Systemd-nspawn kann Container ausführen, Kubernetes orchestriert Container auf Clustern – zwei sehr verschiedene Aufgaben. Kubernetes setzt normalerweise ein Werkzeug wie Runc ein, um die Container tatsächlich auszuführen. Wenn man wollte, könnte man statt Runc auch Systemd-nspawn dafür verwenden, der Infrastruktur sollte nur wenig fehlen. So hat Systemd-nspawn bereits direkte Unterstützung für das Ausführen von OCI-Containern an Bord.

Ich persönlich hege gewisse Zweifel am Kubernetes-Ansatz. Mir scheint da Vieles nicht zu Ende gedacht und mit der heißen Nadel genäht. Deswegen habe ich selbst bisher nichts unternommen, um Systemd-nspawn tatsächlich als Backend für Kubernetes einsetzbar zu machen. Ich denke, ein solcher Ansatz hätte aber durchaus Vorteile in Bezug auf Sicherheit und insbesondere Resource Control.

Grundsätzlich gilt jedoch: Container im Docker-Stil lassen meist nur einzelne Dienste darin laufen, nicht das ganze Betriebssystem. Wie bereits erwähnt, liegt der Fokus von Systemd-nspawn dagegen eher auf Letzterem: Wir wollen es einfach machen, darin volle Linux-Userspaces laufen zu lassen, ähnlich wie in einer VM oder auf einem physikalischen System. Der Fokus von Systemd-nspawn ist also ein etwas anderer als der von Runc und Kubernetes.

Linux-Magazin: Sie schlagen migrierbare Home-Verzeichnisse vor, die die Informationen zum User-Account gleich selbst mitbringen. Funktioniert das nur, wenn der Nutzer sein Home an eigenen Hosts mountet? Oder wer soll sonst ein solches Verzeichnis auf einem portablen Medium erstellen? Im herkömmlichen System sorgt der Schreibschutz für »/etc/passwd« dafür, dass der User seinen Account beispielsweise nicht beliebigen Gruppen hinzufügen kann. Liegen diese Informationen nun direkt im Home-Verzeichnis, sollte sie der Nutzer dort auch nicht editieren dürfen. Wer aber dann, wenn das Verzeichnis an beliebigen Hosts gemountet werden soll?

Lennart Poettering: Typischerweise liegen Home-Verzeichnisse nach wie vor auf der Festplatte etwa des eigenen Laptops. Wenn man sie aber von Systemd-homed verwalten lässt, kann man sie auch etwa auf einen USB-Stick legen und sie sicher zwischen verschiedenen Systemen hin und her bewegen. Ich bin mir sicher, dass das manche Anwender als hilfreich empfinden, doch es ist eher ein Nebeneffekt des Designs und nicht das Ziel. Ich selbst nutze Systemd-homed, um mein Home-Verzeichnis zu verwalten, aber ich speichere es einfach auf der SSD meines Laptops.

Die User-Records, die Systemd-homed verwaltet, sind kryptografisch signiert, und der Daemon akzeptiert nur Records, die zur lokalen Maschine passen. Dieses Signieren und Verifizieren findet komplett automatisch statt, ohne dass der Benutzer es manuell ausführen müsste. Das bedeutet zweierlei: Zum einen können Nutzer nicht ohne Weiteres ihre eigenen User Records modifizieren, es sei denn, sie kennen den geheimen Schlüssel des Systems. Der liegt geschützt unterhalb von »/var« und sollte daher nur dem System und Root bekannt sein. Zum anderen muss man beim Verschieben eines Home-Verzeichnisses von einem System auf ein anderes sicherstellen, dass der Signaturschlüssel des ersten auch auf dem zweiten Rechner akzeptiert wird – das klappt über einfaches Scp.

Linux-Magazin: Herr Poettering, haben Sie herzlichen Dank für das aufschlussreiche Gespräch.