Der neue Dienst Systemd-homed aus der Feder des Systemd-Vaters Lennart Poettering will das Home-Verzeichnis sicherer und gleichzeitig portabel machen.

Auf der Konferenz “All Systems Go” im September 2019 in Berlin [1] stellte Systemd-Entwickler Lennart Poettering ein neues Modul für das Systemmanagement unter Systemd vor. Dieses Mal hatte er unser aller Home-Verzeichnis im Visier, weshalb der Dienst auch schlicht Systemd-homed [2] heißt. Poettering hat dabei primär Notebooks im Unternehmenseinsatz im Sinn; es spricht aber nichts dagegen, ein sichereres Home-Verzeichnis auf dem Notebook oder PC zu Hause umzusetzen. Wir haben überprüft, ob das bereits gelingt.

Nur eine Datei

Der neue Dienst soll das Home-Verzeichnis (im Folgenden kurz als Home apostrophiert) als eine einzelne Datei in einem Container verschlüsseln und somit portabel machen. Die Anwendungsmöglichkeiten reichen von der einfachen Portierung zwischen Notebooks oder PCs mit Bordmitteln wie Rsync bis hin zum voll funktionalen Home in der Hosentasche auf einem USB-Stick. Schließt man Letzteren an einen anderen Linux-Rechner an, steht das Home dort sofort zur Verfügung. Dazu muss der Dienst alle Metadaten eines Users im Home vereinen; Abhängigkeiten zum Restsystem würden die Portabilität unmöglich machen.

Zur Verschlüsselung stehen LUKS und FSCrypt zur Wahl. Bei Letzterem gab es jüngst aber noch Probleme mit Suspend. Als Ablageformate stehen mehrere Backends zur Verfügung. Es kann sich dabei um ein einfaches Verzeichnis oder ein Btrfs-Subvolume handeln. Ähnlich, aber verschlüsselt sind FSCrypt-Verzeichnisse. Beim Netzwerkprotokoll CIFS stellt ein im Benutzerdatensatz des Users konfigurierter Server das Basisverzeichnis bei der Anmeldung bereit.

Als fortschrittlichstes und sicherstes Ablageformat sieht Poettering das nach seiner Methode mit LUKS verschlüsselte Home. Es besteht aus einem Linux-Dateisystem in einem LUKS2-Volume innerhalb einer Loopback-Datei. Als Dateisysteme kommen Ext4, Btrfs und XFS infrage.

Die Einhängepunkte unterscheiden sich je nach gewähltem Format. Bei den verzeichnisbasierten Formaten (einfaches Verzeichnis, Btrfs-Subvolume und FSCrypt) handelt es sich um einen Bind-Mount, bei CIFS um einen CIFS-Netzwerk-Mount und beim LUKS2-Backend um einen Block-Device-Mount des im LUKS2-Image enthaltenen Dateisystems.

Identität

Um alle relevanten Informationen eines Users an einer Stelle zu konzentrieren, dient die in JSON formatierte Datei ~/.identity als User-Record. Dieser Datensatz enthält signierte Informationen über Benutzer, Passwort, Gruppenzugehörigkeiten, die Benutzer- und Gruppen-IDs (UID und GID) sowie weitere Informationen, die sich normalerweise über mehrere Dateien meist unterhalb von /etc verstreuen.

Der jeweilige Host gleicht die Informationen mit einer ihm bekannten Signatur ab. Schlägt der Vergleich fehl, hängt das System das Home nicht ein. Signaturen lassen sich nur mit Root-Rechten auf den Host übertragen. Handelt es sich um einen verschlüsselten Container, so steckt der User-Record im LUKS-Record, sodass er sich ebenfalls verifizieren lässt, bevor das Home entschlüsselt wird.

Noch jung

Seit Systemd 245 ist Systemd-homed Bestandteil von Systemd, wird aber bisher nur von wenigen Distributionen einkompiliert. Weder Debian “Unstable” oder “Testing” noch Ubuntu 20.04 LTS bieten ihren Anwendern an, den neuen Dienst auszuprobieren. Systemd-homed gilt noch als experimentell, wie wir in unserem Test dann auch feststellten.

Wir konnten Systemd-homed bisher lediglich bei Arch Linux und dessen Derivaten wie etwa Manjaro 20.0.3 oder EndeavourOS entdecken, außerdem bei Gentoo und Fedora 32. Die Zurückhaltung der Distributoren erscheint verständlich, sie wollen die doch einschneidende funktionelle Änderung zunächst ausgiebig testen. Zudem gibt es mindestens einen Punkt, der noch der Nachbesserung bedarf: Beim Suspend-to-RAM verbleibt der Key für die Verschlüsselung im RAM, was die Sicherheit untergräbt.

Wir haben Systemd-homed unter Manjaro KDE 20.03 getestet. Falls Sie den Dienst ebenfalls praktisch umsetzen wollen, empfehlen wir, dazu ein dediziertes Testsystem zu nutzen. Sie können recht einfach feststellen, ob der Dienst bei der von Ihnen verwendeten Distribution bereits einkompiliert ist, indem Sie prüfen, ob es im Verzeichnis /usr/lib/systemd/ eine Datei systemd-homed gibt (Listing 1). Ist sie wie bei Arch Linux vorhanden, müssen Sie das Modul noch aktivieren: Das reine Vorliegen der Datei ändert nichts am System.

$ cd /usr/lib/systemd/
$ ls | grep systemd-homed
systemd-homed

Aktivieren

Zum Aktivieren des Diensts nutzen Sie das Tool Systemctl (Abbildung 1). Mit dem Kommando enable weisen Sie Systemd-homed an, beim Start des Rechners aktiv zu werden (Listing 2, erste Zeile). Anschließend starten Sie den Dienst mit dem Kommando start erstmals (zweite Zeile) und prüfen über status den Erfolg der Aktion (letzte Zeile). Der damit assoziierte Dienst Pam_systemd_home sorgt dafür, dass Systemd-homed erfährt, sobald sich ein User an- oder abmeldet.

$ systemctl enable systemd-homed.service
$ systemctl start systemd-homed.service
$ systemctl status systemd-homed.service

Abbildung 1: Wie bei Systemd-Diensten üblich, müssen Sie auch Homed eingangs einmal starten. Mit der Option enable sorgen Sie dafür, dass das bei künftigen Neustarts automatisch passiert.

Sie steuern systemd-homed.service mit dem Werkzeug homectl [3]. Es ermöglicht das Erstellen, Entfernen, Ändern oder Überprüfen von Home-Verzeichnissen. In der einfachsten Variante erstellt homectl create User einen Benutzer mit dem angegebenen Namen, vergibt UID und GID und legt die Standard-Shell auf /bin/bash sowie den Einhängepunkt auf /home/User/ fest.

Machen Sie keine Angaben zum Ablageformat, kommt als Erstes LUKS zum Zug, sofern vorhanden. Falls nicht, aber dient Btrfs als Dateisystem, so erstellt das System ein Subvolume. Trifft weder das eine noch das andere zu, wählt Homectl ein einfaches Verzeichnis. In aller Regel gibt der Anwender aber über Optionen an, welche Eigenschaften das über Systemd-homed verwaltete Home haben soll.

Kreativ werden

Der Befehl homectl --help listet im Abschnitt General User Record Properties die Eigenschaften auf, die das Kommando beim Erstellen eines neuen Homes kennt (Abbildung 2).

Abbildung 2: Der Befehl homectl --help listet unter anderem auch die Eigenschaften des Homes und die Berechtigungen des Users auf, die Sie einem neuen Home mitgeben können.

Der Befehl aus Abbildung 3 erstellt beispielsweise ein Home für den User peter. Peter ist Mitglied in den Gruppen audio, video, users sowie admin, und ihm stehen 2 GByte Speicherplatz zur Verfügung. Das Home verwendet als Format ein einfaches Verzeichnis.

Abbildung 3: Mit dem Befehl homectl create erstellen Sie ein neues Home unter der Kontrolle von Systemd. Nach dem Durchlaufen des Befehls kontrollieren Sie mit homectl list den Erfolg.

An dieser Stelle lässt sich auch ein SSH-Key übergeben, den das System dann in die Datei ~/.identity einträgt. Optional gibt es auch die Möglichkeit, statt der Bash eine andere Shell anzugeben, etwa die Zsh. Nach dem Absetzen des Befehls fragt das System Sie nach einem Passwort, wofür es gleich drei Vorschläge anbietet.

SSH-Key

Ob der User erfolgreich angelegt wurde, zeigt der Befehl homectl list. Dabei fällt auf, dass der neu angelegte Benutzer noch als inaktiv gekennzeichnet ist. Das ändern Sie mit dem Befehl sudo homectl activate peter (Abbildung 4).

Abbildung 4: Nach dem Anlegen eines Homes für einen neuen User aktivieren Sie den Account noch mit homectl activate. Es müssen nicht zu jeder Zeit alle User aktiviert sein.

Haben Sie beim Einrichten des Users ein Detail vergessen, tragen Sie es mit dem Befehl homectl update nach, beispielsweise eine bevorzugte Lokalisierung:

$ homectl update peter --language=de_DE.UTF8

Mit der Option inspect werfen Sie einen Blick auf die Eigenschaften des User-Profils (Abbildung 5). Hier sehen Sie unter anderem den Zeitpunkt der letzten erfolgreichen und der letzten fehlgeschlagenen Anmeldung, die Adresse im Dateibaum, UID und GID, die Gruppenzugehörigkeit sowie eventuelle Quota-Beschränkungen.

Abbildung 5: Der Befehl homectl inspect führt die Eigenschaften eines Users auf.

Enthält die Datei ~/.identity einen SSH-Key (Abbildung 6), so müssen Sie einmalig die SSH-Konfiguration unter /etc/ssh/sshd.config davon in Kenntnis setzen. Dazu dienen die zwei Zeilen aus Listing 3.

Abbildung 6: Die Datei ~/.identity enthält viele der Angaben, die auch inspect liefert, allerdings nur in maschinenlesbarer Form. Zusätzlich liegt dort ein Passwort-Hash.

AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u
AuthorizedKeysCommandUser root

PAM-Fummeleien

Die Rechte von Systemd-homed-Usern finden sich nicht an den üblichen Stellen wie /etc/passwd, /etc/shadow oder /etc/groups. Daher wissen die Authentifizierungsmodule von PAM [4] nichts über den betreffenden User und können ihn daher nicht einloggen. Um das zu erreichen, müssen Sie (laut der einzig auffindbaren Dokumentationsquelle im Arch-Linux-Wiki) eine Datei neu erstellen und eine zweite komplett mit neuem Inhalt versehen.

Da Änderungen an PAM-Modulen einer Operation am offenen Herzen gleichen, sollten Sie diese Anpassungen tunlichst nur auf einem Testsystem nachvollziehen. Die beiden zu ändernden Dateien können Sie aus dem Abschnitt Enabling PAM modules im Arch-Wiki [5] kopieren. Unter Manjaro führte das allerdings nicht zum Erfolg.

Die erste Datei, /etc/pam.d/nss-auth, erstellen Sie neu und befüllen sie. Die darauf Bezug nehmende /etc/pam.d/system-auth passen Sie entsprechend des Beispiels im Wiki an. Dabei kommt es auf die Reihenfolge an: nss-auth muss bereits vorhanden sein, bevor Sie system-auth ändern. Im Test konnten wir uns allerdings auch nach dem Anpassen der beiden Dateien nicht als peter anmelden.

Authselect

Bei Fedora ist hinsichtlich Systemd-homed einiges in Bewegung – was nicht verwundert, da Lennart Poettering und andere Systemd-Betreuer bei Red Hat arbeiten. Daher luden wir kurz vor Redaktionsschluss noch ein tagesaktuelles Abbild von Fedora “Rawhide” herunter, um auch die neuesten Entwicklungen mitzunehmen.

Bei den Diskussionen im Red-Hat-Bugzilla [6] ging es zuletzt darum, wie man den Homed-User ohne Eingriffe in die PAM-Module authentifizieren kann. Hier kommt künftig vermutlich Authselect [7] zum Einsatz, aber noch ist es nicht so weit.

Im Test ließ uns Fedora jedenfalls überhaupt kein Home unter Systemd erstellen. Laut der Fehlermeldung fehlten uns die notwendigen Zugriffsrechte – den Hintergrund konnten wir nicht weiter entwirren.

Fazit und Ausblick

Systemd 245 und somit Systemd-homed wurden im März 2020 freigegeben. Die Kinderkrankheiten dieses tiefen Eingriffs ins Dateisystem sind offenbar noch nicht gänzlich ausgeheilt, weder unter Manjaro noch unter Fedora hatten wir beim Einrichten des Diensts Erfolg. Unter Manjaro konnten wir zumindest einen Benutzer einrichten. Die Methode der Authentifizierung über das Editieren von PAM-Modulen braucht dringend eine gangbare Alternative, soll Systemd-homed Erfolg haben. Fedora könnte mit Authselect auf dem richtigen Weg sein.

Für Anwender mit einem Notebook, auf dem es lediglich ein einzelnes Benutzerkonto gibt, bringt Systemd-homed den Vorteil, dass das Verschlüsselungspasswort dem Login-Passwort entspricht und auch nur einmal abgefragt wird. Arbeiten mehrere Anwender auf einem Gerät, können sie ihre Home-Verzeichnisse separat verschlüsseln.

Kommen mehrere Rechner ins Spiel, erleichtert Systemd-homed das Verschieben von funktionsfähigen Home-Verzeichnissen, etwa mit Rsync. Als weiterer Pluspunkt darf ein mit LUKS verschlüsseltes portables Home auf einem USB-Stick gelten. Wir sehen deshalb in einer der nächsten Ausgaben noch einmal auf den Stand der Dinge bei Systemd-homed. (cla/jlu)