Dies ist eine alte Version des Dokuments!
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.
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 |
LUKS-Partition einrichten:
cryptsetup luksFormat --type=luks1 /dev/sda2
An dieser Stelle wird die künftig zu verwendende Passphrase vorgegeben.
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:
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
/dev/sda2
, sondern im logischen Volume /dev/mapper/cryptdata
erstellt wird.
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:
options="${options:+$options,}subvol=@,ssd,noatime,space_cache,commit=120,compress=zstd"
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:
pass=0
home_options="${options:+$options,}subvol=@home,ssd,noatime,space_cache,commit=120,compress=zstd"
options="${options:+$options,}subvol=@,ssd,noatime,space_cache,commit=120,compress=zstd"
pass=0
options="${options:+$options,}subvol=@home,ssd,noatime,space_cache,commit=120,compress=zstd"
pass=0
echo "$home_path" "$home_mp" btrfs "$home_options" 0 0
compress=zstd
weggelassen), sind die Zeilen 31, 32 und 37 entsprechend anzupassen.
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.
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
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 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 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
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
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
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
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
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:
Prüfen, ob Schlüsseldatei einthalten ist:
lsinitramfs /boot/initrd.img | grep "^cryptroot/keyfiles/"
Erwartete Ausgabe:
cryptroot/keyfiles/cryptdata.key
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…
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 2), 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.