Ubuntu Mate 20.04 auf Btrfs mit Verschlüsselung [ThoSch:Wiki]

Benutzer-Werkzeuge

Webseiten-Werkzeuge


thoschwiki:linux:ubuntumatebtrfsencrypted

Ubuntu Mate 20.04 auf Btrfs mit Verschlüsselung

Bei der Installation soll ein Ubuntu Mate 20.04.1 in einem BTRFS-Filesystem installiert und das System verschlüssel werden.

Da Btrfs (noch?) keinen eigenen Verschlüsselungsmechanismus hat, wird LUKS als Verschlüsselungsebene benutzt, auf der dann das Btrfs-Filesystem aufgesetzt wird. Da GRUB das Entschlüsseln von LUKS-Partitionen im Format luks1 beherrscht, erfolgt die Verschlüsselung im luks1-Format.

Das Installationstool Ubiquity unterstützt diese Art der Installation nicht aktiv. Daher sind manuelle Einriffe vor und nach der eigentlichen Installation notwendig.

Grundlage für das Vorgehen ist eine Anleitung von Willi Mutschler.

Hardware

Die Installation soll auf einem schon in Ehren ergrauten Lenovo Thinkpad R500 (2008-2010 gebaut) mit 8 GiB RAM.

Als Massenspeicher ist eine SDD mit 500 GB verbaut, die wie folgt aufgeteilt ist:

Partition Größe Verwendung spätere LUKS-Bezeichnung
/dev/sda1 ca. 9 GiB bestehendes Bunsen Labs Linux (bleibt bestehen) ohne
/dev/sda2 ca. 446 GiB root-Filesystem der neuen Installation cryptdata
/dev/sda3 10 GiB Swap cryptswap

Vorarbeiten

LUKS-Partition und Btrfs-root-Filesystem anlegen

LUKS-Partition einrichten:

cryptsetup luksFormat --type=luks1 /dev/sda2

An dieser Stelle wird die künftig zu verwendende Passphrase vorgegeben.

In der Bootphase, in der die Passphrase abgefragt wird, ist die Tastatur noch im US-Layout. Dies kann bei der Eingabe der Passphrase zu Problemen führen, wenn Zeichen verwendet werden, die in den verwendeten Tastatur-Layouts auf unterschiedlichen Tasten liegen (siehe Abschnitt Probleme mit der Tastaturbelegung).
cryptsetup luksOpen /dev/sda2 cryptdata

Die eben vorgegebene Passphrase ist einzugeben.

Eine kurze Kontrolle:

ls /dev/mapper/

Es sollte die folgende Ausgabe erscheinen:

control  cryptdata

Es wurde das zusätzliche Volume angelegt.

Im nächsten Schritt wird das Btrfs-Filesystem erstellen:

mkfs.btrfs /dev/mapper/cryptdata
An der Stelle ist darauf hinzuweisen, dass Dateisystem nicht auf dem physikalischem Gerät /dev/sda2, sondern im logischen Volume /dev/mapper/cryptdata erstellt wird.

Mount-Option für SSD anpassen (Optional)

Da die Installation auf einer SSD erfolgt, können/sollten hier entsprechende Optionen für den mount-Vorgang vorgegeben werden:

nano /usr/lib/partman/mount.d/70btrfs

Hier können die folgenden Änderungen vorgenommen werden:

  • Zeite 24:
    options="${options:+$options,}subvol=@,ssd,noatime,space_cache,commit=120,compress=zstd"
  • Zeile 31:
    options="${options:+$options,}subvol=@home,ssd,noatime,space_cache,commit=120,compress=zstd"

Da die Hardware bereits etwas älter ist, habe ich auf den Option compress=zstd verzichtet (Komma davor entfernen).

Entsprechende Folgeänderungen:

nano /usr/lib/partman/fstab.d/btrfs

Hier können die folgenden Änderungen vorgenommen werden:

  • Zeite 30:
    pass=0
  • Zeite 31:
    home_options="${options:+$options,}subvol=@home,ssd,noatime,space_cache,commit=120,compress=zstd"
  • Zeite 32:
    options="${options:+$options,}subvol=@,ssd,noatime,space_cache,commit=120,compress=zstd"
  • Zeite 36:
    pass=0
  • Zeite 37:
    options="${options:+$options,}subvol=@home,ssd,noatime,space_cache,commit=120,compress=zstd"
  • Zeite 40:
    pass=0
  • Zeite 56:
    echo "$home_path" "$home_mp" btrfs "$home_options" 0 0
Sofern man im vorherigen Schritt Anpassungen an den Optionen vorgenommen hat (hier: compress=zstd weggelassen), sind die Zeilen 31, 32 und 37 entsprechend anzupassen.

Installation durchführen

Für die eigentliche Installation kann das Installationstool Ubiquity genutzt werden. Da das Tool eine im verschlüsselten root-Filesystem liegende „boot-Partition“ nicht unterstützt, muss das Erstellen des Bootloaders unterdrückt werden.

ubiquity --no-bootloader 

Entsprechend dem obigen Layout der SSD sind bei den zu verwendenden Partitionen die folgenden Vorgaben zu machen:

Gerät Formieren als Mountpoint
/dev/mapper/cryptdata btrfs /
/dev/sda3 swap

Am Ende der Installation startet mn nicht ins das frisch intsallierte system, sondern lässt das Fenster des Installationsprogrammes offen oder wählt Weiter ausprobieren.

Nacharbeiten

Nach der eigentlichen Installation sind sind noch Anpassungen am Krypto-Setup vorzunehmen und der Bootloader einzurichten.

Als erste Schritt wechselt man in eine Change-root-Umgebung mit dem frisch installiertem System:

mount -o subvol=@,ssd,noatime,space_cache,commit=120,compress=zstd /dev/mapper/cryptdata /mnt
mount -o subvol=@home,ssd,noatime,space_cache,commit=120,compress=zstd /dev/mapper/cryptdata /mnt/home
Sofern man bei den Vorarbeiten Anpassungen an den Mount-Optionen vorgenommen hat (hier: compress=zstd weggelassen), sind beim mount die Optionen (-o subvol=@,ssd,noatime… entsprechend anzupassen.
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc/
sudo chroot /mnt

Eine kurze Kontrolle, ob alles richtig steht:

Alles richtig gemountet?

mount -av

Ergebnis:

/                        : ignoriert
/home                    : bereits eingehängt
none                     : ignoriert

Und die Btrfs-Subvolumes:

btrfs subvolume list /

Ergebnis:

ID 256 gen 160 top level 5 path @
ID 257 gen 14 top level 5 path @home
Die Ausgaben können je nach individueller (Hardware)Konfiguration unterschiedlich ausfallen.

cryptab für das root-Filesystem erstellen

Die Einträge für die /etc/crypttab werden manuell angelegt:

export UUIDVDA3=$(blkid -s UUID -o value /dev/sda2) #this is an environmental variable
echo "cryptdata UUID=${UUIDVDA3} none luks" >> /etc/crypttab

Und die /etc/crypttab zu Kontrolle anzeigen…

cat /etc/crypttab

Ausgabe:

cryptdata UUID=8a06f062-cd19-4b53-917e-65461f5e27c7 none luks
(Die angezeigte UUID wird auf jeden Fall abweichen; ist halt unique:-))

Swap verschlüsseln

Die Swap-Partition sollte auch verschlüsselt werden. Ich weiche hier vom Vorgehen von Willi Mutschler mit einem zufälligen Schlüssel ab, weil ich ggf. Hibernate oder Suspend-to-Disk nutzen möchte.

Zunächst wird die entsprechende Partition ähnlich der root-Partition vorbereitet:

swapoff /dev/sda3   # swap deaktivieren, falls aktiv
cryptsetup luksFormat --type=luks1 /dev/sda3

An dieser Stelle wird die künftig zu verwendende Passphrase vorgegegeben.

cryptsetup luksOpen /dev/sda3 cryptswap  # Volumename abweichend von /root

Die eben vorgegebene Passphrase ist einzugeben.

Eine kurze Kontrolle:

ls /dev/mapper/

Es sollte die folgende Ausgabe erscheinen:

control  cryptdata  cryptswap

Es wurde ein zusätzliche Volume angelegt.

Im nächsten Schritt wird das Volume als Swap initialisiert:

mkswap /dev/mapper/cryptswap

Wiederum die Einträge für /etc/crypttab manuell anlegen:

export SWAPUUID=$(blkid -s UUID -o value /dev/sda3)
echo "cryptswap UUID=${SWAPUUID} none luks" >> /etc/crypttab

Abschließend ist die geänderte Swap-Konfiguration noch in die /etc/fstab einzutragen. Hierbei die UUID der Swap-Partition durch die Volume-Bezeichnung /dev/mapper/cryptswap zu ersetzen:

Editor mit /etc/fstab öffnen:

nano /etc/fstab

Entsprechende Zeile wie folgt ändern:

/dev/mapper/cryptswap none            swap    sw              0       0

Schlüsseldatei implementieren (Optional)

Bei diesem Stand der Konfiguration würde(n) die Passphrase(n) mehrfach abgefragt werden. Um dies zu vermeiden kann man das Entschlüsseln beim Mounten auf eine Schlüsseldatei umstellen. Diese Schlüsseldatei liegt abgesichert im root-Filesystem, dass in einem erscten Schritt mit der einmaligen Eingabe der Passphrase entschlüsselt wird.

Anlegen und Sichern der Schlüsseldatei im neuen Verzeichnis /etc/luks:

mkdir /etc/luks
dd if=/dev/urandom of=/etc/luks/boot_os.keyfile bs=4096 count=1
chmod u=rx,go-rwx /etc/luks
chmod u=r,go-rwx /etc/luks/boot_os.keyfile

Nun wird der Schlüssel jeweils in den zweiten Key-Slot abgelegt:

cryptsetup luksAddKey /dev/sda2 /etc/luks/boot_os.keyfile   # /
cryptsetup luksAddKey /dev/sda3 /etc/luks/boot_os.keyfile   # swap
Sofern nach dem Ausführen eines der beiden Befehle die Meldung
Kein Schlüssel mit dieser Passphrase verfügbar.

ausgegeben wird, wurde die Passphrase nicht korrekt eingegeben.

Anschließend – mit dem jeweiligen Gerätenamen – prüfen, ob dies erfolgreich war:

cryptsetup luksDump /dev/sda2 | grep "Key Slot"

Erwartete Ausgabe:

Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Anschließend die gleiche Prüfung für /dev/sda3 durchführen.

Weitere Sicherungsmaßnahmen:

echo "KEYFILE_PATTERN=/etc/luks/*.keyfile" >> /etc/cryptsetup-initramfs/conf-hook
echo "UMASK=0077" >> /etc/initramfs-tools/initramfs.conf

Abschließend nocht die /etc/crypttab anpassen:

sed -i "s|none|/etc/luks/boot_os.keyfile|" /etc/crypttab # this replaces none with /etc/luks/boot_os.keyfile

Die /etc/crypttab sollte dann diese Struktur haben:

cryptdata UUID=8a06f062-cd19-4b53-917e-65461f5e27c7 /etc/luks/boot_os.keyfile luks
cryptswap UUID=9bd99c32-3d25-42a3-95d5-d819b153d5b2 /etc/luks/boot_os.keyfile luks
(Die angezeigten UUIDs werden auf jeden Fall abweichen; sind halt unique:-))

Bootloader GRUB installieren

Abschließend it noch der Bootloader GRUB zu installieren.

Verschlüsselung GRUB aktivieren:

echo "GRUB_ENABLE_CRYPTODISK=y" >> /etc/default/grub

Kernelbezogene Software aktualisieren/ergänzen:

apt install -y --reinstall grub-efi-amd64-signed linux-generic linux-headers-generic linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04
Sofern man – wie im hier vorliegenden Fall – Hardware ohne UEFI verwendet, wird man das Paket grub-efi-amd64-signed weglassen können.

Initramfs und GRUB aktualisieren und installieren:

update-initramfs -c -k all
grub-install /dev/sda
update-grub

Prüfen, ob die rechte auf die /boot/initrd.img restriktiv gesetzt sind:

stat -L -c "%A  %n" /boot/initrd.img

Erwartete Ausgabe:

  1. rw——- /boot/initrd.img

Prüfen, ob Schlüsseldatei einthalten ist:

lsinitramfs /boot/initrd.img | grep "^cryptroot/keyfiles/"

Erwartete Ausgabe:

cryptroot/keyfiles/cryptdata.key

Reboot

An dieser Stelle sollte alles fertig sein und man kann das neue System zum ersten Mal booten.

Sofern noch in der Change-root-Umgebung ist, muss man diese verlassen:

exit

Dann der Reboot

reboot

Da ist der Moment zum Daumendrücken, Beten, whatever…

In der Bootphase, in der die Passphrase abgefragt wird, ist die Tastatur noch im US-Layout. Dies kann bei der Eingabe der Passphrase zu Problemen führen, wenn Zeichen verwendet werden, die in den verwendeten Tastatur-Layouts auf unterschiedlichen Tasten liegen (siehe Abschnitt Probleme mit der Tastaturbelegung).

Probleme mit der Tastaturbelegung

In der Bootphase, in der die Passphrase abgefragt wird, ist die Tastatur noch im US-Layout. Dies kann bei der Eingabe der Passphrase zu Problemen führen, wenn Zeichen verwendet werden, die in den verwendeten Tastatur-Layouts auf unterschiedlichen Tasten liegen.

Neben den üblichen Verdächtigen (y, z sowie Umlaute ä, ö, ü und ?) betrifft es die meisten der für die Verwendung in Passworten immer wieder empfohlenen Sonderzeichen (beispielsweise „&/=?#*+-<>()[]{}“, vgl Tastaturbelegung USA).

Hierfür gibt es drei Lösungsstrategien:

  • Die problematischen Zeichen meiden (nur Buchstaben außer y und z sowie Zahlen verwenden)
  • die Lage der problematischen Zeichen im US-Layout merken und entsprechend „blind“ tippen
  • die gewünschte Zeichenfolge in der „US-Tippweise“ als zusätzliche Passphrase1) vorgeben (z.B. „yulu>echo“ statt „zulu:echo“)

Sofern man eine zusätzliche Passphrase hinzufügen möchte, kann man zuerst den Zustand der Key-Stores ermitteln:

# cryptsetup luksDump /dev/sda2 | grep "Key Slot"
Key Slot 0: ENABLED
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Die zusätzliche Passphrase wird dann folgt hinzugefügt:2):

# cryptsetup luksAddKey /dev/sda2
Geben Sie irgendeine bestehende Passphrase ein: 
Geben Sie die neue Passphrase für das Schlüsselfach ein: 
Passphrase bestätigen: 
Sofern nach der Abfrage der bestehenden Passphrase die Meldung
Kein Schlüssel mit dieser Passphrase verfügbar.

ausgegeben wird, wurde die Passphrase nicht korrekt eingegeben.

Abschließend noch den Zustand des Key-Stores prüfen:

# cryptsetup luksDump /dev/sda2 | grep "Key Slot"
Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Es sollte nun ein Key-Slot mehr belegt sein.

Wurde für die verschlüsselte Swap-Partition eine Schlüsseldatei eingerichtet, dann ist es ausreichend nur für das root-Filesystem eine weitere Passphrase vorzugeben.

Fazit

Als ich die Anleitung von Willi Mutschler das erste Mal durchlas, war ich erschlagen und ging davon aus, dass ich das Konzept – wenn überhaupt – nur 1:1, Zeile für Zeile nachbauen könnte.

Da in dem Artikel ausreichend Hintergrundinformationen enthalten sind 3), konnte ich mir Stück für die Stück die Thematik erarbeiten. Dazu trug sicherlich bei, dass ich parallel mein Vorgehen im vorliegenden Artikel dokumentierte und es dafür sprachlich aufbereiten musste.

Gegen Ende war mir dann schon möglich, ein eigene, von der Vorlage abweichendes Vorgehen für die Swap-Partition zu erarbeiten und umzusetzen.

Quellen

1)
LUKS erlaubt 8 Passphrase bzw. Schlüssel pro Volume
2)
Sofern nicht bereits ein Konsole mit root-Rechten geöffnet ist, muss ein sudo vorangestellt werden
3)
Die im vorliegenden Artikel teilweise fehlen.
thoschwiki/linux/ubuntumatebtrfsencrypted.txt · Zuletzt geändert: 27.06.2021 19:22 von thosch