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. Apr 15:53 /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...