Aktuell gilt bei Linux auf dem Desktop: Ganz oder gar nicht. Entweder eine Vollverschlüsselung mit LUKS oder ein unverschlüsseltes System. Ältere Lösungen wie eCryptFS werden nicht weiter entwickelt, aber mit systemd-homed steht mehr als ein Ersatz in den Startlöchern.
Abgrenzung zu anderen Lösungen
Linux hat für die Verschlüsselung von Partitionen und Systemen eine hervorragende Lösung namens LUKS (dm-crypt). Mit LUKS kann man einzelne Partitionen oder externe Festplatten verschlüsseln und die meisten Distributionen bieten an, damit das komplette Betriebssystem zu verschlüsseln.
LUKS ist eine gute und sichere Lösung, aber sie hat ein paar Nachteile bzw. Bereiche, die sie einfach nicht abdeckt. Durch die Vollverschlüsselung verlagert sich die Passwortabfrage an den Start des Betriebssystems. Je nach Konfiguration vor oder nach dem Bootloader GRUB. Ist das System während des Startvorgangs einmal entschlüsselt, liegen die Daten offen. Das ist nicht nur bei der heutzutage verbreiteten Nutzung von Standby ein Problem, sondern auch bei Mehrbenutzersystemen. Man kann LUKS dann mit verschiedenen Passwörtern ausstatten und andere Workarounds vornehmen. Das Kernproblem bleibt: LUKS liegt konzeptionell quer zum Displaymanager-System der Desktopumgebungen, weshalb diese von vielen dann bei Einzelnutzersystemen per Autologin übersprungen werden oder eine doppelte Passwortabfrage notwendig ist. Bei Mehrbenutzersystemen kommt man um eine doppelte Passwortabfrage nicht umhin.
Neben dieser “Komfortproblematik” schützt eine Vollverschlüsselung mittels LUKS die Benutzer auch nicht gegeneinander. Hier greifen dann wieder nur die üblichen Dateirechte der Distributionen.
Zur Benutzerdatenverschlüsselung gab es früher eCryptFS, das lange Zeit von Ubuntu favorisiert wurde (hier eine ältere Anleitung). Mit dem Weggang des Hauptentwicklers von Canonical liegt eCryptFS nun faktisch brach. Es gibt zahlreiche offene Bugs und zeitweilig gab es ernste Sicherheitsprobleme, die jedoch zuletzt noch behoben wurden. Aber klar sein dürfte auch, dass es keine substanzielle Weiterentwicklung von eCryptFS mehr gibt. Die Zukunft gehört nicht eCryptFS.
systemd-homed – Verschlüsselung und mehr
Konzept – Home-Verzeichnis im Container
systemd-homed zählt zu den neueren Entwicklungen im systemd-Umfeld. 2019 skizzierte Lennart Poettering grob das geplante Konzept und 2020 stellt er es auf der FOSDEM 20 vor. Die Gemeinschaft diskutierte das Konzept vor allem im Kontext sogenannter portabler Home-Verzeichnis.
Der Hintergrund, warum systemd-homed vor allem in diesem Kontext wahrgenommen wurde, liegt in seiner Konzeption. So bietet systemd-homed die Möglichkeit, das Home-Verzeichnis eines Benutzers beispielsweise in einer Loopback-Datei abzulegen oder auf einen USB-Stick zu speichern. Dieses Desiderat griffen viele dankbar auf.
Langfristig gehört systemd-homed aber zu einer ganzen Reihe von Maßnahmen, um Linux sicherer zu machen und überkommene Methoden und ihre Limitationen abzuschütteln. In seinem Artikel von 2021 stellte Lennart Poettering Ideen und Ansätze vor, um Linux hier voranzubringen. Dazu gehören Konzepte wie eine ein verifizierter Startvorgang (woran nicht nur Poettering arbeitet) oder die stärkere Einbeziehung von Secure Boot und TPM. Erst beim Login sollen dann das Home-Verzeichnis des Anwenders entschlüsselt werden, dessen Schutz nicht an die restlichen Schutzmaßnahmen des Systems gekoppelt ist.
Genau an diesem Punkt bietet systemd-homed bereits jetzt spannende Funktionen. Es kann nämlich das Homeverzeichnis mit verschiedenen Mechanismen verschlüsseln, die über das hinausgehen, was bisher mit Linux möglich ist und bietet ebenso die Möglichkeit, die Authentifizierung an einen FIDO2-Keys (z. B. ein YubiKey) oder eine Smartcard zu koppeln. Hier zahlen sich andere Entwicklungen im systemd-Kontext wie systemd-cryptsetup aus.
Unterschiedliche Möglichkeiten: LUKS, fscrypt oder ohne Verschlüsselung
Es gibt unterschiedliche Optionen, ein Home-Verzeichnis mit systemd-homed zu betreiben. Eine davon ist ansonsten für Linux noch überhaupt nicht verbreitet. Grundsätzlich basieren alle Lösungen auf einem verschlüsselten Verzeichnis /home/<benutzername>.homedir. Beim Login wird dies regulär als /home/<benutzername> eingehängt.
- Nicht verschlüsseltes Btrfs-Subvolume: Obwohl Verschlüsselung konzeptionell in systemd-homed vorgesehen ist, kann man auch einfach das Home-Verzeichnis auf einem Btrfs-Subvolume ohne Verschlüsselung ablegen.
- Verschlüsselung mit ext4 und fscrypt: Google hat für Android vor einiger Zeit eine native Dateisystemverschlüsselung namens fscrypt entwickelt. Diese existiert für die Dateisysteme ext4, F2FS und UBIFS. Relevant für Linux ist hier primär ext4. Die Verschlüsselung erfolgt als transparente dateibasierte Verschlüsselung und ist nicht so sicher wie z. B. LUKS.
- Verschlüsselung mit LUKS: Hier wird dateisystemunabhängig ein LUKS-Volume in einer Loopback-Datei erzeugt. Innerhalb des LUKS-Volume findet ext4, Btrfs oder XFS Verwendung. Diese Lösung ist mit Abstand die sicherste Variante.
Ein nicht verschlüsseltes Home-Verzeichnis bringt aktuell keine Vorteile und macht meiner Ansicht nach erst als Option Sinn, wenn systemd-homed mal “Standard” in der Linux-Welt ist.
Die transparente Verschlüsselung mit fscrypt und die containerbasierte LUKS-Variante haben beide Vor- und Nachteile. LUKS ist sicherer und ein etablierter Standard. Der Container hat aber eine definierte Größe, die entweder konkret in GB oder in Prozent angegeben wird. Die Partition mit den Home-Verzeichnissen ist dann entsprechend belegt, selbst wenn innerhalb des Containers noch viel Platz ist. Fscrypt ist hier viel flexibler und orientiert sich einfach an der Partitionsgröße, aber dafür nicht so sicher, weil die Metadaten der Dateien offen liegen. Dafür ist der LUKS-Ansatz flexibler, was die Wahl des Dateisystems betrifft, während fscrypt quasi ext4 vorschreibt.
Die Möglichkeit, fscrypt zu nutzen, ist zudem momentan das größte Alleinstellungsmerkmal von systemd-homed.
Es ist also eine Abwägung des notwendigen Schutzbedarfs. Wenn man z. B. bereits ein vollständig mit LUKS verschlüsseltes System nutzt und nur noch zusätzlich die einzelnen Benutzer gegeneinander abschirmen möchte oder wenn man nicht besonders schutzwürdige Daten hat und nur neugierige “Gelegenheitsspione” aussperren möchte, dann ist fscrypt mehr als ausreichend.
Grundsätzlich ist das Schutzniveau, wenn man nur die Benutzerdaten verschlüsselt und nicht das gesamte System, nicht so hoch, wie bei einer vollständigen Verschlüsselung des Systems mit LUKS, weil unverschlüsselte Daten in anderen Bereichen gespeichert sein könnten, wie z. B. in /tmp. Das war auch bei eCryptFS schon so und ist somit nicht neu.
Einrichtung mit fscrypt am Beispiel von openSUSE Tumbleweed
systemd-homed ist immer noch neu und experimentell. Es sollte noch nicht für Produktivsysteme genutzt werden und es werden tiefergehende Linux-Kenntnisse vorausgesetzt.
systemd-homed steht noch nicht für alle Distributionen zur Verfügung. Paketiert haben es moderne Distributionen wie Arch Linux (inkl. dem Abkömmling Manjaro), Fedora und openSUSE Tumbleweed. Distributionen wie Debian müssen vermutlich erst noch einige Jahren Diskussionen über “Unix-Principles” führen, bevor sie nachziehen.
Im folgenden Szenario gehe von einem openSUSE-System aus, das wie folgt partitioniert ist.
- EFI
- Systempartition mit Btrfs
- Homepartition mit ext4
Wirklich wichtig ist die Homepartition mit ext4. Ob es Auswirkungen hat, wenn z. B. alle Partitionen in einem verschlüsselten LVM sind, wurde aber nicht getestet. Wenn man ein frisches System für den Test verwendet, kann man auch in der Installationsroutine auf das Anlegen eines Benutzers verzichten.
Die Einrichtung geschieht auf einem TTY. Hier wechselt man auf dem Loginbildschirm (z. B. SDDM oder GDM) per Strg + ALt F1 auf die Konsole.
Für die Verwendung von systemd-homed sind zusätzliche Pakete und Veränderungen an PAM notwendig.
# zypper in systemd-experimental nss-systemdAnschließend verändert man die PAM-Einstellungen für systemd-homed. Hierzu ist keine manuelle Bearbeitung notwendig, sondern das geschieht mit folgendem Befehl:
# pam-config -a --systemd_homeAnschließend ist noch manuell eine Datei zu bearbeiten: /etc/nsswitch.conf Hier folgende zwei Zeilen wie folgt um den Zusatz systemd ergänzen:
passwd: compat systemd
group: compat systemdHiernach aktiviert man den homed-Service:
# systemctl enable --now systemd-homedWenn man ein LUKS-Homeverzeichnis anlegen möchte, reicht das bereits, für fscrypt muss das ext4-Dateisystem ggf. angepasst werden. Dazu muss die Partition zuerst ausgehängt werden.
# umout /homeNun muss noch das Dateisystem optimiert, der Checksums-Support aktiviert und das Dateisystem auf 64bit konvertiert werden. Pfadangaben sind entsprechend auf das ext4-Dateisystem für das Home-Verzeichnis anzupassen. Je nach Standardkonfiguration sind manche Schritte davon vielleicht nicht notwendig, das Dateisystem meldet dann, dass die Funktion bereits aktiviert ist. Das ist also nicht schädlich.
# e2fsck -Df /dev/<disk>
# resize2fs -b /dev/<disk>
# tune2fs -O metadata_csum /dev/<disk>
Nun muss noch fscrypt aktiviert werden:
# tune2fs -O encrypt /dev/<disk>Anschließend überprüfen, ob alle notwendigen Funktionen aktiviert sind.
# dumpe2fs -h /dev/<disk>| grep features:Die Ausgabe sollte wie folgt aussehen. Wichtig ist vor allem encypt bei den Filesystem Features.
dumpe2fs 1.46.4 (18-Aug-2021)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg encrypt sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Journal features: journalLinux_incompat_revoke journal_64bit journal_checksum_v3
Nun muss man entweder die Home-Partiton wieder einhängen oder zur Sicherheit einmal komplett neustarten und auf das TTY zurückkehren.
Benutzer verwaltet man für systemd-homed mittels des Tools homectl. Mit folgendem Befehl legt man einen neuen Benutzer an und nutzt fscrypt ohne Quota.
# homectl create <username> --storage=fscryptAnschließend neustarten und sich wie gewohnt z. B. via SDDM einlogen.
Probleme und Grenzen
Aktuell gibt es natürlich noch einige Limitationen, schließlich ist das Ganze kaum zwei Jahre alt. Grafische Tools wie die Benutzerverwaltung von KDE, SDDM oder auch der YaST Usermanager erkennen den mittels homectl angelegten Benutzer nicht. Das hat z. B. zur Folge, dass man beim Loginbildschirm Benutzername und Passwort eingeben muss und keinen Benutzer per Icon auswählen kann.
Die Verwaltung der Benutzer erfolgt ebenso nur über homectl, weshalb Tipps im Internet oder Informationen über Systemmeldungen, wie man Benutzer zu Gruppen hinzufügt und ähnliches, nicht funktionieren.
Abgesehen davon sind im Test bisher keine Probleme aufgetreten.
Zusammengefasst
Wie so oft haben die Entwickler rund um systemd ein Desiderat erkannt und es erfolgreich geschlossen. Hier passiert seit Jahren viel von dem, was Linux substanziell voranbringt.
Das noch ziemlich neue systemd-homed ist jetzt schon stabiler und ausgereifter als eCryptFS es nach Jahren der Entwicklung war. Die Integration in die grafischen Lösungen ist vermutlich nur eine Frage der Zeit. Ähnlich wie bei allen Entwicklungen im Kontext von systemd wird homed einen starken Vereinheitlichungsschub für die diversen Linux-Distribtionen und ihre verschiedenen, historisch gewachsenen Lösungen bringen.
Was heute noch experimentell ist, wird morgen schon Standard sein.
Hallo Gerrit, vielen Dank für deinen aufklärenden Artikel! Ich bringe systemd-homed aber noch nicht so ganz zusammen mit dem, was mir beim Aufsetzen von z.B. Mint angeboten wird: Ist systemd-homed das, was einem als “Home-Verzeichnis verschlüsseln” angeboten wird, wenn man sein System nicht mit LUKS verschlüsselt?
Nein, systemd-homed gibt es noch nicht in produktiven Linux-Distributionen, sondern es ist aktuell noch im experimentellen Bereich. Das was du meinst, ist das veraltete eCryptFS. Es ist typisch Mint, so etwas auf die Nutzer loszulassen, obwohl es Ubuntu schon aus dem Standard geworfen hat und jederzeit komplett rauswerfen könnte.