FOSDEM 2023: Eine Festung mit Systemd und TPM-Chip

Inhaltsverzeichnis

Systemd-Entwickler Lennart Poettering hat auf der FOSDEM 2023 die neuesten Fähigkeiten des Init-Dämons für Linux skizziert: Systemd kann in der kommenden Version die Integrität einer Linux-Distribution anhand verschiedener Merkmale verifizieren und dann im TPM-Chip (Trusted Platform Module) hinterlegte Geheimnisse abrufen. In Zukunft soll Systemd auch einen umfassenden kryptografischen Fingerabdruck des Systems samt Software bereitstellen. Das letzte Anwendungsbeispiel ist laut Poettering eine Methode, um anhand des TPM von Serversystemen aus der Ferne zu überprüfen, ob dort ein unverändertes System-Image beziehungsweise eine zuvor signiert Softwareumgebung läuft.

Systemd wird zum Toolkit für TPM

Bei neuen Systemd-Fähigkeiten ist nie ganz abzusehen, welche Linux-Distributionen diese übernehmen. Denn Systemd und seine Dienste und Tools sind modular. Die Nutzung von TPM 2.0 ist mit Systemd aber keineswegs Science-Fiction. Schon seit Version 248 erlauben die Komponenten "systemd-cryptenroll" zusammen mit "systemd-cryptsetup" in Fedora sowie Arch Linux ein automatisches Entschlüsseln von LUKS2-Laufwerken anhand des hinterlegten und mit Prüfwerten versiegelten Schlüssels im TPM-Chip. Von Haus aus nutzt Systemd dabei das Platform Configuration Register (PCR) Nummer 7, das den Prüfwert von Secure Boot und der Signatur des gestarteten Kernels vergleicht.

Ein anderes gebootetes Live-System oder ein abgeschalteter Secure Boot liefert dabei unterschiedliche Prüfwerte für PCR 7 zurück und TPM rückt den Schlüssel nicht heraus. Die Absicherung eines Linux-Systems mit PCR 7 erlaubt weiterhin Updates von (signierten) Kernel-Versionen über die jeweiligen Paketmanager, ist in ihren Möglichkeiten aber begrenzt – schließlich beachtet der Prüfwert nur den Status von Secure Boot und den Kernel. Das kommende Systemd der Version 253 will deshalb weitere PCRs des Trusted Platform Module verfügbar machen, um auch den Status installierter Software auf einem Linux-System einzubeziehen.

Nur für imagebasierte Linux-Distributionen

Eines vorweg: Praktikabel ist das bei traditionellen, paketbasierten Distributionen überhaupt nicht. Poettering hat diesen Ansatz exklusiv für imagebasierte Linux-Systeme wie Fedora Silverblue, Kiniote oder Endless OS entwickelt. Der Distributor liefert diese als vorgefertigtes Komplettpaket aus und aktualisiert sie auch nur als Ganzes. Von Anwendern installierte Software wird als App-Container wie Flatpak hinzugefügt und die Benutzerdaten liegen stets auf einer anderen Partition als das System. Laut Poettering gehört diesen Linux-Systemen in vielen Anwendungsbereichen die Zukunft, denn der Distributor kann ein signiertes Betriebssystemimage samt vorinstallierter Software und Standardkonfiguration ausliefern.

Die hinterlegten Prüfwerte im TPM-Chip können dann während des Boots ermitteln, ob es sich noch um ein unmodizifiertes System-Image handelt. System 253 nutzt dazu auf Wunsch drei PCRs für Kernel, Kernel-Bootparameter, Initrd und für die Identifikation des Systemimages. Die neuen Tools dazu sind "systemd-measure", das PCR-Prüfwerte errechnet und signiert, sowie "systemd-creds" als Schlüsselbund, das Berechtigungsnachweise bei einer Übereinstimmung von erwarteten und beim Boot ermittelten PCRs-Werten entsperrt. Dazu gesellen sich laut den Folien von Poetterings Talk bewährte Sicherheitsvorkehrungen wie ein optionales Passwort oder Rate-Limiting bei der Abfrage des TPM.

Ein erweiterter Fingerabdruck für Systeme

Nach der Übersicht zum aktuellen Entwicklungsstand ging es im kurzen, aber wortreichen Vortrag um die zukünftigen Anwendungsszenarien: Auf Servern können PCRs als Fingerabdruck dienen, der auch Kernel und installierte Software einbezieht sowie aus der Ferne abrufbar ist. Auf Notebooks und Desktops kann Systemd mit TPM sicherstellen, dass in Abwesenheit kein erfolgreicher "Evil Maid"-Angriff stattfand, der ein manipuliertes System hinterlässt. Auch die Konfiguration von Serverdiensten könnte Systemd überprüfen, wenn diese als Imagedatei vorliegt und in Zielverzeichnisse unterhalb von "/etc" gemountet wird.

Kein kleines Hindernis, das Poettering für diese Checks aus der Ferne noch meistern muss, ist die Ausgabe von TPM-Daten in ein vertrauenswürdiges Logsystem. Ein eigenes Eventlog soll es dafür in Systemd nicht geben, das wäre zu aufwändig und auch fehleranfällig. Möglichst soll eine Bibliothek für das schon vorgesehene TPM-Eventlog von der Trusted Computing Group zum Einsatz kommen, die seit 2009 auch hinter TPM steht.

(bme)