Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – X – Hibernation

In den zurückliegenden Artikeln dieser Serie hatte ich Vorüberlegungen und konkrete Maßnahmen zur Installation eines voll-verschlüsselten Laptops dargestellt:

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VIII – Systemd-Fehler nach Neustart
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IX – Verschlüsselter SWAP

Auf dieser Basis hatten wir zuletzt eine einfache “Opensuse Leap 15”-Variante auf einer externen SSD mit “LUKS on LVM”-Volumes zum Laufen gebracht. Wir können diese Installation bereits in einen Konsolen-Modus booten und Shutdowns durchführen.

Sowohl Grub2 als auch der Kernel fragen uns im Boot-Vorgang erwartungsgemäß nach LUKS-Passphrases für den Zugang zum jeweiligen Master-Key der bislang verschlüsselten zwei Raw-Volumes, die uns quasi als Krypto-Container für das root-Filesystem [“/”-FS] und den SWAP dienen. Wir haben die Volumes aus Gründen der Flexibilität in zwei separaten Volume Groups [VGs] untergebracht; die Passphrases für die Volumes wurden identisch gewählt, um statt 4 nur 2 Eingaben durchführen zu müssen. So weit – so gut.

Der Einsatz eines Laptops ist allerdings auch dadurch geprägt, dass man das System manchmal zügig in einen inaktiven (und stromsparenden) Zustand versetzen muss – ohne dass man dabei den Status laufender Applikationen verlieren will. Ein typisches Beispiel ist etwa das Schließen eines Laptops für einen Raum-, Zug- oder Flugzeug-Wechsel. Unsere Anforderung ist dabei weniger Geschwindigkeit als vielmehr Sicherheit. Dies spricht für Hibernation (s.u.).

Wir wollen in diesem Beitrag deshalb einen ersten Kurztest des Hibernation-Verhaltens unseres Laptops durchführen. Im Zuge dieser Aktivitäten lernen wir leider auch, dass weder das Herunterfahren in den Hibernation-Zustand – noch der Resume-Vorgang unter Leap 15 frei
von Fehlermeldungen sind. Dennoch funktioniert Hibernation – zumindest auf meinem System.

Einschränkungen:

  • Ich betrachte hier – wie in den vorhergehenden Artikeln – nur ein klassisches BIOS-System und keine UEFI-basiertes System. Das wirkt sich (je nach Linux-Distribution) u.a. auf die Grub2-Konfiguration aus; u.a. können die Namen der Konfigurationsdateien abweichen. Die dort zu setzenden Kernel-Parameter sind typischerweise aber gleich.
  • Hibernation und ein später folgender Resume-Vorgang aus einem Hibernation Zustand sind relativ komplexe Prozesse. Für eine erfolgreiche Wake-Up-Phase sind initial ggf. auch BIOS- oder UEFI- und ACPI-Funktionen erforderlich. Das BIOS muss den sog. S4-Zustand unterstützen. Sind diese Funktionen nicht standardgerecht implementiert, kann es auf bestimmten Systemen zu Problemen kommen, die ich hier nicht aufgreifen kann. Man muss sich ggf. um ein BIOS-Update bemühen. Die Linux-Kernel-, GRUB- und systemd-Entwickler haben aber versucht, das Thema Hibernation so weit als möglich unter eigene Kontrolle zu bringen.
  • Wir betrachten im Moment nur einen Start/Resume-Vorgang in einen Konsolen-Modus (früher Runlevel 3; heute Multi-User-Target). Diese Einschränkung ist durchaus bedeutsam, da im Falle von grafischen Komponenten Video-Systeme restauriert werden müssen; das ist bei bestimmten Systemen, u.a. Optimus-Systemen, durchaus ein problembehaftetes Thema. Ich komme in einem späteren Artikel darauf zurück.

Continue reading

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IX – Verschlüsselter SWAP

Ich setze meinen Ausflug in das Setup eines Opensuse Laptops mit Voll-Verschlüsselung fort:

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VIII – Systemd-Fehler nach Neustart

Die Leser der bisherigen Artikel erinnern sich sicher daran, dass ich während der Installation von Leap 15 auf einem verschlüsselten LUKS-Volume vermieden hatte, ein ebenfalls verschlüsseltes SWAP-Volume einzubinden. Der SWAP wird weder in der Grub2-Konfiguration, noch in der “/etc/fstab” oder der “/etc/crypttab” des Root-Filesystems der Installation referenziert. Wir werden dies nun nachträglich ändern.

Wir schließen unseren Laptop ans LAN an und booten die Leap 15-Installation von unserem verschlüsselten LUKS-Volume “/dev/vga/lva1” (LUKS on LVM) auf der externen SSD. Da wir während der Installation bereits den SSH-Service aktivieren ließen und die lokale Firewall deaktivierten, können wir uns nun bequemerweise von einem externen System einloggen. Wem das nicht möglich ist, muss halt an einem Konsolen-Terminal des Laptops arbeiten. Uns steht im Moment noch kein grafischer Desktop zur Verfügung; Arbeiten auf der Kommandozeile ist notwendig. FS steht nachfolgend wie immer für “Filesystem”.

Continue reading

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VIII – Systemd-Fehler nach Neustart

Im letzten Beitrag dieser Serie

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM

hatte ich beschrieben, dass wir während einer Opensuse-Installation mit selbst konfigurierten LUKS-Volumes (LUKS on LVM) manuell dafür sorgen müssen, dass die Datei “/etc/crypttab” im künftigen “/”-FS existiert, bevor der Installer gegen Ende der Installation “dracut” aufruft. Der Opensuse-Installer unterstützt uns dabei leider nicht :-(.

Sollte das jedoch schief gegangen sein oder sollte die selbst verfasste “/etc/crypttab” einen falschen Eintrag aufweisen, schlägt der erste Systemstart nach der Installation fehl. Ich gehe davon aus, dass das zu bootende LUKS-Volume mit LUKS1 (und nicht LUKS2) für die Verschlüsselung formatiert wurde, so dass Grub2 es ansprechen kann. Man wird dann zwar noch von Grub2 nach der Passphrase für das LUKS-Volume mit dem “/”-FS” gefragt und erhält auch noch das grafische Grub-Menu mit einer Auswahl an bootbaren Systemen. Der nachfolgende systemd-Start aus dem initramfs schlägt jedoch fehl. Die Fehler münden nach einem längeren Warten auf einen Time-Out schließlich in den Start einer “dracut”-Emergency-Shell mit zugehörigem Prompt.

Hier kann man aber manuell einen Versuch zur Korrektur der unvollständigen Konfiguration von initramfs und systemd unternehmen – ohne die langwierige Installation komplett wiederholen zu müssen.

Das, was ich nachfolgend beschreibe, kann aber auch nützlich sein, wenn man in späteren Stadien irgendwelche Fehler in die “/etc/crypttab” eingebracht hat – und man das System nicht mehr vollständig von seinen verschlüsselten LUKS-Volumes booten kann.

Mit FS kürze ich nachfolgend “Filesystem” ab.

Continue reading