Komplett verschlüsseltes Fedora

Wie kann man sensible Daten auf einem Notebook schützen, wenn diese über das gesamte Dateisystem verteilt sind? Und funktioniert eine Verschlüsselung in einem aktuellen Fedora 7 oder 8, das 32 bzw. 64 Bit hat, relativ problemlos? Erfahrend Sie nachfolgend, wie Sie Ihr Fedora-System komplett, d.h. mit Root- und Swap-Partition, verschlüsseln können.

Wenn Sie sensible oder sehr private Daten auf Ihrem Rechner bzw. Laptop haben, so sollten Sie sich überlegen, diese zu schützen, damit - beispielsweise im Falle eines Diebstahls - diese Daten weiterhin geschützt bleiben und damit für den Angreifer unbrauchbar sind. Eine sichere Verschlüsselung umfasst hierbei die Root- und die Swap-Partition, sofern sich alle zu schützenden Daten innerhalb dieser beiden Partitionen befinden. Sollten sich Ihre sensiblen Daten ausschließlich auf einer separaten Partition befinden, die nicht als Root- oder Swap-Partition dient (was jedoch nur selten der Fall ist), so ist diese Anleitung für Sie nur von mäßiger Bedeutung, da eine solche Konfiguration spätestens seit Fedora 8 von Haus aus mittels /etc/crypttab problemlos möglich ist.

Als erstes installieren Sie Fedora 7 oder 8 auf Ihrem Computer oder Notebook. Hierbei reicht eine Standardinstallation völlig aus, Sie können natürlich individuelle Einstellungen vornehmen. Im Verlauf dieser Anleitung gehe ich von nachfolgender Partitionierung bzw. LVM-Konfiguration aus; sofern diese auf Sie nicht zutrifft, müssen Sie diese logisch auf Ihr System anpassen. In jedem Fall ist jedoch eine separate /boot-Partition zwingend erforderlich, hierfür reichen glücklicherweise bereits 50 MB völlig aus.

Teil der Festplatte Normale klassische Partitionierung Fedora-typische LVM-Konfiguration
/boot /dev/sda1 /dev/sda1
Swap /dev/sda2 /dev/VolGroup00/LogVol00
Root /dev/sda3 /dev/VolGroup00/LogVol01

Selbstverständlich können Sie auch ein bestehendes Fedora-System verschlüsseln, sofern Sie die unbedingt benötigte /boot-Partition bereits haben. Das verwendete Dateisystem sollte jeweils ext3 bzw. Swap sein. Von der Einrichtung selbst her sehe ich keine Probleme bei anderen unterstützten Dateisystemen, jedoch kann ich bei ReiserFS, JFS oder XFS keinen nennenswerten Vorteil auf einem normalen (vielleicht sogar portablen) Computer sehen.

Nach der Installation von Fedora müssen noch einige Pakete nachinstalliert werden, da die mitgelieferten Skripte, die die Initrd für den Kernel erzeugen, bislang keine Unterstützung für verschlüsselte Dateisysteme bereitstellen. Bei den von mir bereitgestellten Paketen habe ich auf die Patches im Bugreport "Add encrypted root filesystem support to mkinitrd" aus dem Red Hat Bugzilla zurückgegriffen und die Patches so angepasst, dass diese bei normaler Partitionierung und mit LVM funktionieren sollten. Die nachfolgenden RPM-Pakete liegen auf meinem FTP-Server und können auch von dort heruntergeladen werden.

Version Binäre RPM-Pakete Source-RPM
Fedora 7 (i386) mkinitrd mkinitrd-devel mkinitrd-debuginfo libbdevid-python nash mkinitrd
Fedora 7 (x86_64) mkinitrd mkinitrd-devel mkinitrd-debuginfo libbdevid-python nash
Fedora 7 (ppc) mkinitrd mkinitrd-devel mkinitrd-debuginfo libbdevid-python nash
Fedora 7 (ppc64) mkinitrd mkinitrd-devel mkinitrd-debuginfo libbdevid-python nash
Fedora 8 (i386) mkinitrd mkinitrd-devel mkinitrd-debuginfo libbdevid-python nash mkinitrd
Fedora 8 (x86_64) mkinitrd mkinitrd-devel mkinitrd-debuginfo libbdevid-python nash
Fedora 8 (ppc) mkinitrd mkinitrd-devel mkinitrd-debuginfo libbdevid-python nash
Fedora 8 (ppc64) mkinitrd mkinitrd-devel mkinitrd-debuginfo libbdevid-python nash

Im Normalfall benötigen Sie lediglich die Pakete "mkinitrd" und "nash". Mit "rpm -q <Paket>" können Sie vor der Installation meiner Pakete herausfinden, welche Pakete Sie zur Zeit installiert haben bzw. welche Sie benötigen werden. Beachten Sie bitte unbedingt, dass die interne Versionsnummer dieser RPM-Pakete so weit erhöht worden ist, dass eventuelle Fedora-spezifische Updates für diese Pakete niemals eingespielt werden - denn diese würden die Unterstützung für verschlüsselte Dateisysteme im Skript, das bei der Installation eines Kernels zum Einsatz kommt, wieder entfernen und Ihr System schlimmstenfalls nicht mehr startbar machen. Installiert werden die benötigten Pakete dann beispielsweise wie folgt:

tux:~ # rpm -Uvh mkinitrd-6.0.19-4.fc8.i386.rpm nash-6.0.19-4.fc8.i386.rpm
Vorbereiten...              ########################################### [100%]
   1:mkinitrd               ########################################### [ 50%]
   2:nash                   ########################################### [100%]
tux:~ # 

Für den nächsten Schritt benötigen Sie eine Fedora Live-CD bzw. Live-DVD, welche Sie von der Download-Seite des Fedora Projects für die Hardware-Plattformen i386/i686, x86_64 und ppc herunterladen können. Ebenfalls ist eine externe Festplatte oder ein USB-Stick erforderlich, welcher mindestens so groß ist, dass er den aktuellen Inhalt Ihrer Root-Partition fassen kann. Und damit die Berechtigungen auf den Dateien und Verzeichnissen später erhalten bleiben, muss die externe USB-Festplatte bzw. der USB-Speicherstick das ext3-Dateisystem (oder ein anderes Linux-typisches Dateisystem) haben. Starten Sie den Computer neu, booten ihn vom Fedora Live-Medium und wechseln Sie anschließend mittels Strg+Alt+F1 an eine Konsole. An dieser führen Sie nachfolgende Befehle aus, um SELinux und die Benutzung der Swap-Partition durch das System auf dem Live-Medium zu deaktivieren:

live:~ # setenforce 0
live:~ # swapoff -a

Bitte beachten Sie, dass Sie die beiden oben genannten Befehle erneut ausführen müssen, wenn Sie z.B. zu einem späteren Zeitpunkt erneut von einem Fedora Live-Medium booten, um einen eventuellen Fehler bei dieser Einrichtung zu korrigieren. Legen Sie nun einen neuen Mountpoint an und hängen Sie ihre bestehende interne Festplatte auf diesen ein.

live:~ # mkdir /mnt/intern
live:~ # mount /dev/sda3 /mnt/intern

Erzeugen Sie anschließend den Einhängepunkt für die externe USB-Festplatte bzw. für das USB-Massenspeichergerät und hängen dieses ebenfalls ein.

live:~ # mkdir /mnt/usb
live:~ # mount /dev/sdb1 /mnt/usb

Ist beides eingehängt, so können Sie den Inhalt Ihrer Root-Partition auf das externe Speichermedium kopieren. Verwenden Sie dazu am besten den folgenden Befehl, welcher die bestehenden Berechtigungen von Dateien und Verzeichnissen erhält:

live:~ # cp -ax /mnt/intern/* /mnt/usb

Hängen Sie nach dem erfolgreichen Kopiervorgang Ihre interne Festplatte vom Mountpoint wieder aus und schreddern Sie mit dem zweiten Befehl sämtliche Daten auf der angegebenen Root-Partition, damit sich nur noch zufällige Daten auf dieser befinden. Dieser Schritt wird benötigt, um zu verschleiern, wo die Verschlüsselung beginnt und endet - dadurch werden im schlimmsten Fall die Möglichkeiten zum Erlangen von Informationen für den Angreifer minimiert bzw. erschwert.

live:~ # umount /mnt/intern
live:~ # 
live:~ # shred -v /dev/sda3

Je nach Größe und Geschwindigkeit Ihrer Festplatte kann dies unter Umständen sehr lange dauern; daher ist es meines Erachtens eine gute Idee, diesen Schritt einfach über Nacht durchzuführen. Anschließend können die verschlüsselten Container mit den nachfolgenden Aufrufen angelegt werden. Für die Swap- und die Root-Partition muss das Passwort jeweils zweimal eingegeben werden, hierbei muss das Passwort für die Swap-Partition nicht das gleiche wie für die Root-Partition sein:

live:~ # cryptsetup -y -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/sda2
live:~ # cryptsetup -y -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/sda3

Danach müssen die beiden Container geöffnet werden, damit Sie die Dateisysteme darauf wieder anlegen können, um im nächsten Schritt den Inhalt Ihrer Festplatte vom externen Medium wieder zurückspielen zu können.

live:~ # cryptsetup luksOpen /dev/sda2 swap
live:~ # cryptsetup luksOpen /dev/sda3 root
live:~ # 
live:~ # mke2fs -j -L "/" /dev/mapper/root
live:~ # mkswap /dev/mapper/swap
live:~ # 
live:~ # mount /dev/mapper/root /mnt/intern
live:~ # cp -ax /mnt/usb/* /mnt/intern

Bitte beachten Sie, dass wenn Sie zukünftig von irgendeinem Live-Medium (beispielsweise Fedora Live-Medien, Knoppix) booten, diese Ihre verschlüsselte Swap-Partition mit einem einfachen "mkswap" sofort bereits beim Bootvorgang überschreiben. In einem solchen Fall müssen Sie die hier beschriebenen Swap-spezifischen Schritte erneut wiederholen. Dies kann Ihnen auch passieren, wenn die Einrichtung nicht auf Anhieb funktioniert und Sie eine Korrektur mittels Fedora Live-Medium vornehmen müssen. Glücklicherweise lassen jedoch alle Live-Medien, die mir bislang untergekommen sind, die verschlüsselte Root-Partition in Ruhe.

Sofern Sie auf Ihrem System SELinux nicht deaktiviert haben, es also auf "Enforced" oder "Permissive" steht, sollten Sie das Dateisystem neu labeln, damit die SELinux-Labels im Dateisystem wieder korrekt gesetzt werden. Hierzu legen Sie einfach die Datei "/mnt/intern/.autorelabel" an, damit die Initskripte sich später beim Booten des Rechners auch darum kümmern.

live:~ # touch /mnt/intern/.autorelabel

Ist dies alles geschehen, so muss die neue initiale RAM-Disk mit der Unterstützung für die verschlüsselten Partitionen erzeugt werden. Dazu wechseln Sie zuerst in eine Chroot-Umgebung und mounten beispielsweise die benötigten Dinge:

live:~ # chroot /mnt/intern
tux:~ # 
tux:~ # mount -t proc proc /proc
tux:~ # mount -t sysfs sysfs /sys
tux:~ # mount /dev/sda1 /boot
tux:~ # 
tux:~ # dmsetup mknodes

In einzelnen Fällen kann es passieren, dass die Gerätedatei "/dev/sda1" nicht existiert. Sie können diese dann einfach von Hand anlegen.

tux:~ # mknod /dev/sda1 b 8 1

Die dafür benötigten Informationen können Sie ganz einfach auf einer anderen Konsole der Fedora Live-CD ermitteln:

live:~ # ls -l /dev/sda1
brw-rw---- 1 root disk 8, 1 19. Jul 03:30 /dev/sda1
live:~ # 

Auch bei der Verwendung von LVM kann es gelegentlich zu einer fehlenden Gerätedatei kommen, in diesem Fall ist beispielweise folgendes notwendig:

tux:~ # ln -s /dev/mapper/VolGroup00-LogVol00 /dev/VolGroup00/LogVol00

Nun muss die Datei "/etc/fstab" an die neuen Gerätedateien, welche mit dem verschlüsselten Container verknüpft sind, angepasst werden. Dazu wird das Label bzw. die Gerätedatei der Root- und der Swap-Partition gegen "/dev/mapper/root" für die Root-Partition und für die Swap-Partition gegen "/dev/mapper/swap" ausgetauscht. Anschließend könnte die Datei z.B. so aussehen:

LABEL=/boot             /boot                 ext3    defaults        1 2
/dev/mapper/swap        swap                  swap    defaults        0 0
/dev/mapper/root        /                     ext3    defaults        1 1
tmpfs                   /dev/shm              tmpfs   defaults        0 0
devpts                  /dev/pts              devpts  gid=5,mode=620  0 0
sysfs                   /sys                  sysfs   defaults        0 0
proc                    /proc                 proc    defaults        0 0

Sofern bei der Root- oder Swap-Partition noch "/dev/sda2", "/dev/VolGroup00/LogVol00" oder "LABEL=/" steht, wird Ihr System nach dem Neustart nicht booten; korrigieren Sie daher die Einträge bitte wirklich sehr sorgfältig. Als letzten größeren Schritt wird nun die initiale RAM-Disk selbst angelegt, verwenden Sie dazu nachfolgenden Aufruf und passen diesen für Ihre Kernel-Version entsprechend an:

tux:~ # /sbin/mkinitrd -v -f /boot/initrd-2.6.23.1-42.fc8.img 2.6.23.1-42.fc8

Bitte überprüfen Sie, ob die Ausgabe dieses Befehls irgendwelche Verweise auf die Kernel-Module "dm-crypt", "blkcipher", "cbc", "aes" und "sha256" enthält. Zudem muss am Ende der Ausgabe der Text "Assuming manual passphrase entry" zweimal kurz hintereinander auftauchen. Ist dies nicht der Fall, so kann das Skript zum Erzeugen der Initrd (RAM-Disk) keinen verschlüsselten Container bzw. Gerät auffinden. Wenn Sie an dieser Stelle keine Korrektur vornehmen, damit die erforderliche Ausgabe zustandekommt, werden Sie Ihr System nach dem Neustart nicht booten können. Meist ist die Ursache für fehlende Kernel-Module in der Konsolenausgabe von "mkinitrd" ein fehlerhafter Eintrag in der Datei "/etc/fstab" bei der Root- oder Swap-Partition.

Beachten Sie auch, dass die Datei "/etc/grub.conf" nicht abgeändert werden darf, obwohl die Datei "/etc/fstab" für die Root- und Swap-Partition nicht mehr auf die eigentliche Gerätedatei bzw. auf das LVM-Device zeigt. Lassen Sie die Grub-Konfiguration einfach so, wie sie derzeit ist. Und damit ist nun die Einrichtung einer vollständig verschlüsselten Fedora-Installation soweit abgeschlossen. Verlassen Sie zum Schluss noch die Chroot-Umgebung, hängen die Geräte aus, starten Ihr System neu und entfernen das Fedora Live-Medium:

tux:~ # umount /boot
tux:~ # umount /proc
tux:~ # umount /sys
tux:~ # exit
live:~ # 
live:~ # umount /mnt/intern
live:~ # reboot

Kurz nach dem Grub-Bootmanager werden Sie beim Starten Ihres Systems nun zweimal nach einem Passwort gefragt. Das erste Passwort ist für die Swap-Partition, das zweite für die Root-Partition. Sofern Sie "Suspend-to-Disk" verwenden, werden Sie lediglich nach dem Swap-Passwort gefragt, da das Passwort für die Root-Partition sich im (verschlüsselten) Swap befindet. Übrigens funktioniert "Suspend-to-Disk" auch mit kompletter Verschlüsselung einwandfrei, sofern es bereits ohne diese ebenfalls funktioniert hat...