ALLE ACHTUNG! Dieser Eintrag ist obsolet. Mit den aktuellen Installations-Datentraegern der Distributionen Debian und Ubuntu laesst sich das unten beschriebene Setup ebenfalls durchfuehren (ohne externes Gebastel). Die Scripte werden daher nicht mehr weiter angepasst (und duerften inzwischen aufgrund geaenderter Ordnerstrukturen fuer das initramfs auch nicht mehr funktionieren). Ich danke euch fuer eurer unermuedliches Fehlersuchen :).
Achtung bitte. Dieser Eintrag wurde mehrfach aktualisiert. Bitte beachte auch die Updates am Ende des Eintrages. Diese koennten ergaenzend zum Eintrag selber schon Fragen loesen oder Anhaltspunkte fuer weitere Informationsbeschaffung leisten. Danke 
Nochmal Achtung! Inzwischen gibt es unter blog.roothell.org eine aktuellere Anleitung fuer alle Ubuntu Dapper Benutzer, die auch ohne weiteres mit Dapper Drake funktionieren soll. Danke an alle, die mir dies mitgeteilt haben.
Hallo liebe unbaendige Fangemeinde dieser prosaischen Hirnvergewaltigung. Heute war ein guter Tag… zumindest fuer die meisten Menschen auf diesem Planeten. Valentingstag ist ein Tag der Liebe, der Zuneigung und der Gestaendnisse. Nichts der gleichen erreichte mich, bis auf eine einsame traurig schauende digitale Rose meiner Cousine, die mich sehr gefreut hat. Naja… seis drum. Ein Nerd ist ein Nerd. Wer beliebt sein will sollte sich andere Hobbys suchen und in der Stadt herumlaufen, mit den teuren Klamotten rumprollend. Das ist nicht so mein Ding, da behalte ich doch lieber all das Geld ein und gebe es fuer den ganzen Kram aus, der kaputt geht und ersetzt werden muss… siehe mein iBook. Noch immer koennte ich mir die Stimmbaender aus dem Hals fluchen.
So aehnlich muss ich heute morgen auch geklungen haben. Erstmal war die Nacht recht kurz da ich gestern Abend noch, Gott allein weiss wie, mein Notebook,bzw das Debian darauf abgeschossen habe. Zusaetzlich dazu hat mich eine Erkaeltung dahingerafft… oder sagen wir “hatte”… ich leide nie sehr lange darunter und meistens ist das mit viel Tee und meiner Lieblingsmusik in wenigen Stunden ausgesessen. Ich war als heute nicht in der Firma, hatte quasi Schonfrist ;). Was macht ein Nerd an so einem Tag? …
Zu dieser Frage sollte man als interessierte Persoenlichkeit zunaechst folgenden Gegensatz zu verstehen versuchen. Nerds sind, obgleich sie der Oeffentlichkeit gegenueber haeufig zu Schreckhaftigkeit neigen leicht von jeglicher technischer Spielerei zu begeistern. Auch wenn diese erst mit gewisser Zurueckhaltung und Skepsis beaeugt wird zieht sie den gekoederten Nerd rasch in ihren Bann und wird so lange nicht losgelassen bis sie an allen Enden pfeift und blinkt. Dem entgegen steht der oft auch nur technischen Massnahmen zur Datensicherheit vorgeschobene Schutz der Privatsphaere, deren interessante Seite mich am heutigen Tag zu fesseln drohte. Ich spreche mit diesen geschwollenen Worten vom tool ‘cryptsetup’ (die Variante mit LUKS). Dieses kleine Wunderknaeul aus Prozeduren und Variablen ist in der Lage mittels des Kernel Device Mappers in Linux eine Abstraktionsebene zwischen den Benutzer und die Hardware zu schieben, die eine transparente Verschluesselung zulaesst (Beschrieben im Linux Magazin 08/2005 incl des technischen Hintergrundes den beiseite zu lassen ich gedachte). Diese Abstaktionsschicht, die ich im fortlaufenden einfach beim Namen des zustaendigen Kernel-Moduls nenne (”dm-crypt”) laesst auf herrlich einfache und sichere Art und Weise ganze Dateisysteme hinter dem mystischen Schleier der Kryptographie verschwinden. Im Einsatz ist dieses Verfahren seit etwa 07/2005 in diesem Haushalt zur Speicherung von Gespraechsdaten und Schluesseln auf der PBX4Linux Telefonanlage und bisher konnte ich nicht klagen, was Leistung oder Zuverlaessigkeit angeht. Allerdings ist in diesem Fall nur ein Teil des Dateisystems verschluesselt.
Wie ich bereits sagte war das Debian auf meinem Notebook eh schwer beschaedigt und da mich diese Crypto-Technik immer wieder dazu antreibt zu lesen, zu verstehen und auszuprobieren wagte ich es, einen ersten Versuch zu einer Crypto Root FS Installation zu unternehmen. Der Haken dabei ist, dass schon sehr frueh beim Booten, wenn das Wurzeldateisystem auf dem die Programme (unter anderem zum Initialisieren des Crypto-Dateisystems) liegen noch nicht verfuegbar ist, ein Programm zum Aktivieren des Device-Mappers im Kernel gestartet werden muss. Debian konnte das bis vor kurzem noch (als sie noch mkinitrd und klassische cramfs initrds, winzige dateisysteme mit den zum booten wichtigsten Prograemmchen, benutzten). Die HowTos in der Cryptsetup-Dokumentation und im Internet, die ich zu debian und gentoo gefunden habe benutzten fast alle dieses Verfahren. Da mit der Umstellung von devfs oder classical dev auf udev im Kernel auch die Umstellung von initrds zu initramfs (anstatt cramfs kommen hier cpio Archive zum Einsatz) einher ging sind diese HowTos, was die Pre-Root-Mount Abschnitte - also die, die beschreiben, wie man ein verschluesseltes Root FS mountet - angeht unbrauchbar. Im Versuch liess sich auch der Kernel mit der aus der sonst recht hilfreichen Dokumentation von cryptsetup (die man unter /usr/share/doc/cryptsetup/CryptoRoot.HowTo findet) erstellten initrd nicht booten, bzw fand dieser das dm-crypt Laufwerk nicht. Vielleicht war das ein Problem mit LUKS.
Das neuere cryptsetup aus unstable (aktuell leider nicht das aus testing und stable, weshalb unbedingt vorher aktualisiert werden muss) unterstuetzt die wunderbaren LUKS Erweiterungen. LUKS steht fuer “Linux Unified Key Setup” und ist quasi ein Header auf dm-crypt Laufwerken, in dem mehrere Schluessel fuer mehrere Benutzer etc festgelegt werden koennen und noch vieles mehr. Weitere Infos dazu gibts unter http://luks.endorphin.org. Auch wenn das Initialisieren eines solchen Laufwerkes wesendlich einfacher ist, muss man darauf achten, dass das cryptsetup mit dem man arbeitet dies auch unterstuetzt. Das war z.B. bei der Gentoo Live CD aus dem 2005.1er Release nicht der Fall. Bei INSERT unterstuetzte der aktuelle Kernel nicht die noetigen aes ciphers und somit musste ich eh neu installieren. (Kleine Anmerkung an dieser Stelle: Ich zog noch einige andere CDs in erwaegung, aber ich wollte auch noch fertig werden und habe mich daher fuer eine etwas exotische, wenn auch in vielerlei Hinsicht vorteilhaftere Methode entschieden)
(Es folgt eine Anleitung in der bitte jede Leserin und jeser Leser aufmerksam darauf achtet die Werte, Pfade und Devicenamen an das eigene System anzupassen. Diese Anleitung ist fuer Menschen, die wissen was sie tun.)
Wie bereits vor einigen Tagen erwaehnt, das Notebook ist des Nerdes Freund.. demnach hat mans immer dabei und kann es sich nicht erlauben wenn mal was nicht tut. Bei meinem Firmennotebook ergibt sich zuseatzlich die schwierigkeit, dass ich ueber einen unpowered (4Wire) FireWire Port von CD booten muss. Daher eruebrigt sich das Mitfuehren einer Knoppix CD. Die recht Geraeumige 80GB HDD ermoeglicht allerdings das Unterbringen einer speziell auf die Rettung von Daten und Systemen ausgelegten Debian Installation von unter 1GB, die ich gleichsam zum zusammenstellen des dm-crypt root und des initramfs benutzen moechte.
Zur Installation von Debian nehme ich in der Regel direkt einen Debian Installer Daily Snapshot. Die Dinger tun oft genug und sind aktuell. _SO_ mag ich das. Ausserdem kommt man schnell ran und muss nur um die 100 MB herunterladen (http://www.debian.org/devel/debian-installer/). Herunterladen, Brennen und es kann losgehen (die unglaublichen Szenen bei den Versuchen das FireWire CD Laufwerk ans laufen zu bringen erspare ich euch… gleichzeitig enthalte ich euch auch noch mehrere Lachkraempfe vor, aber wir sind ja zum Arbeiten hier… nicht zum tratschen.)
Das Partitionieruntsschema ist recht einfach:
- hda1: ca 350MB Boot (ext2) - Ich mag es gerne geraeumig und bastel viel mit kerneln. Ausserdem wusste ich noch nicht wie gross das initramfs mit all den tools nacher werden wuerde. Nummer sicher! Im Debian Installer setzen wir die Partition auf “Formatieren” und “Benutzen als ext2″. Da wir Grub benutzen koennten wir auch XFS oder ext3 nehmen… aber warum ein journal? der Mountpunkt ist /boot
- hda2: ca 780MB Swap (noch kein FS! der swapspace wird auch verschluesselt ;)) - Ich habe 384MB Ram, das ist weniger als 512MB, daher muss ich nach der Faustregel aus meinen fruehen Linuxtagen das doppelte an swap nehmen. Ich bin bisher ganz gut mit der groesse gefahren.
- hda3: ca 7.5GB Root (auch noch kein FS, dafuer sind wir heite hier) - Das Root Dateisystem traegt nacher nicht das /home directory, also darf ist es mit 7.5GB fuer ein statisches Arbeitssystem schon ganz schoen geraeumig. Wir haben den Platz ja schliesslich.
- hda5: ca 800MB Rescue Root (ext3) - Hier rein installieren wir erstmal. Das teil rettet uns nacher unseren Kragen, wenn mit dem Hauptsystem unterwegs mal die Pferde durchgehen. Im Debian Installer setzen wir es auf “Formatieren” und “Benutzen als ext3″. Der Mountpunkt ist /
- hda6: ca 50 GB Home (noch nix, auch das /home wird verschluesselt) - Das Homedir traegt spaeter die Benutzerverzeichnisse. Ich neige dazu da allen moeglichen Krams reinzuwerfen, daher hab ich hier auch etwas platz vorgesehen.
- hda7: der Rest. Ich werfe hier ziemlich viel speicher ueber Bord, aber man weiss ja nie. Vielleicht will ich mal eine andere Distri testen oder so. Ich lasse die restlichen >10GB mal frei und harre der Dinge die da kommen.
Unser Debian Installer fuehlt sich also etwas beengt, denn bisher weiss er nur von den beiden putzigen Partitioenchen von insgesamt etwas ueber 1GB. Das ist / (hda5) und /boot (hda1). Wir installieren hier erstmal das Basissystem rein, installieren auf nachfrage grub und machen weiter. Ich mag grub eher, weil er im Zweifel eine kleine shell zum schnellen korrigieren der Parameter und der Kernel-Namen bietet. Sowas hat LILO irgendwie nicht. Schade.
Nach der Installation des Basis Systems bereiten wir die Installation des Crypto-Root sorgfaeltig vor. Zu installieren sind cryptsetup, das 2.6.15 (das ist gerade aktuell… wenn du das liest vielleicht auch schon wieder veraltet) kernel image fuer unseren Prozessor (ich nehme hier 686, da ich einen Pentium III besitze) und, sollte das nicht eh schon passiert sein, die initramfs-tools. Natuerlich installiert hier auch jeder seinen lieblingseditor und alle tools, die man auf der konsole zur wiederherstellung braucht. Meine lieblinge sind hte (Paket ht), partimage, parted und einige Andere dinger die mir gerade nicht einfallen.
Der Knackpunkt ist wie gesagt das initramfs. Von hier aus muss die Passphrase abgefragt werden, der device-mapper eingerichtet und das LUKS initialisiert werden. Das macht zwar alles ein kleiner Befehl, aber an diesem haengt ein Rattenschwanz an Bibliotheken die alle in das kleine Image rein muessen. Zum GLUECK habe ich festgestellt, dass die initramfs tools einem hier die ganze arbeit abnehmen und Abhaengigkeiten aufloesen. Damit es allerdings ueberhaupt was zum mounten gibt muessen wir den krams erstmal verschluesseln. Wer hier nach einem HowTo fuer das uebernehmen einer bestehenden Installation sucht, dem muss ich leider absagen. Vielleicht bringt es aber auch was weiterzulesen. Die Installationsprozedur ist fast die selbe.
Spaetestens an dieser Stelle solltest du den aktuellen Kernel gebootet haben. Wenn nicht, neu starten. der 2.6.15 kann alles was wir brauchen. Zur Anwendung wird kommen: ein dm-crypt LUKS mit aes-cbc-essiv:sha256 cipher. Das bedeutet, wir benutzen Cryptsetup mit LUKS Support, AES als Verschluesselungs-Algorithmus, wenden diese als Zyklische Block Chiffre, damit in Blocks zufaellig gleiche Fragmente nicht auch in der verschluesselten Kopie gleich aussehen. Danach salzen wir diesen Zyklus noch mit einem Initialisierungsvektor, der gehashed wird. Damit verhintert man Wartermarking Angriffe. Die Details sind BITTE dem LM zu entnehmen ;). Ich will nicht noch mehr ueber die Technik sagen.
Schreiten wir also zur Tat: hda3 ist unser erstes Opfer. Nach der Tabelle oben muesste hier hinein das Root Dateisystem in das wir spaeter das Grundsystem kopieren. Damit das geht, und der Kernel weiss, dass es sich hierbei um den Physischen Raum fuer ein verschluesseltes Dateisystem handelt benutzen wir jetzt (ich hoere einige zum xten mal aufatmen, “Kommt der Junge jetzt endlich zur Sache”) erstmalig cryptsetup. Die Manpage ist auf jeden Fall einen Blick wert! (Folgende cryptsetup Aktionen werden bitte als root ausgefuehrt, da wir direkt mit den BLock devices arbeiten)
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/hda3
(Einige HowTos fuellen vorher die HDD mit Zufallsdaten. Dies kann aus kryptoanalytischer Sicht Sinn machen um Bereiche in denen verschluesselte Daten liegen nicht offensichtlich zu zeigen. Ich habe darauf verzichtet. Die Manpage von “shred” hilft weiter, wenn dieser Schritt gewuenscht wird.)
Die Nachfrage von Cryptsetup (die hoffentlich alle angezeit bekommen… ansonsten ist wohl ein Fehler aufgetreten) LESEN WIR SORGFAELTIG und bestaetigen sie dann mit YES (alles schoen brav gross schreiben). Wir werden 2x nach einer Passphrase gefragt, nach deren 2 maliger korrekter Eingabe alle Daten auf /dev/hda3 verloren gegangen sind (ich hab doch gesagt… LESEN ;)). Jetzt sind hoffentlich alle Header geschrieben. Die Passphrase ist optimalerweise sehr lang, dennoch leicht zu merken und schwer zu erraten. Ganze Saetze mit Zahlen und Satzzeichen machen das ganze interessant. Wichtig jedoch ist, dass zum Zeitpunkt der Passphrase eingabe die lokalisierten Tastaturtreiber noch nicht geladen sind (Anmerkung vom 23.2.06: Das stimmt inzwischen nicht mehr ganz. In der aktuellen Version sollte die Keymap, die sowieso vom System beim booten geladen wird mit in das initramfs gepackt werden). Verzichte also auf z,y, Klammern, Semikoli und andere Frechdachse, die sich auf der englischen Tastatur ganz wo anders verkrochen haben (zumindest Umlaute sollte man auch dann beiseite lassen, wenn man nach dem 23.2.06 installiert hat).
Die Parameter erklaeren sich wie folgt: -c legt die oben bereits erklaerte cipher fest, -y laesst cryptsetup 2x nach einer Passphrase fragen und -s ist die laenge unseres Schluessels in Bit. 256 Bit ist fuer AES das aktuell unterstuetzte Maximum. luksFormat ist die durchzufuehrende Aktion (Formatieren mit LUKS) und /dev/hda3 das zu formatierende Geraet. Haeufig wurde ich gefragt ob man auch ein anderes Dateisystem als LUKS verwenden kann… aber hier ist schon die Frage in die falsche Richtung gedacht. LUKS ist nicht etwa schon das Dateisystem, sondern nur die Vorbereitung fuer das transparente dm-crypt. Das Dateisystem erstellen wir spaeter…
Noch ist allerdings unser verschluesselter Datenspeicher noch nicht sichtbar… das ist auch besser so. Was wir sehen lenkt uns vom wesendlichen ab. Wir sollten uns gleich an das wichtige gewoehnen und durch Wiederholung lernen. Schliesslich haben wir ja noch unsere Home Partition hda6 (oder aehnlich). Mit ihr verfahren wir erneut wie oben beschrieben.
Ist das erledigt ist es Zeit zum spielen. Wir aktivieren kurz mal beide dm-crypt mappings um erstens zu schauen wie das geht und zweitens um zu sehen ob wir uns noch an die Passphrase erinnern. Letzteres ist besonders wichtig. Ich merke hier noch einmal an (andere Dokumentationen haben das sicher auch schon getan) dass Daten aus einem Crypto-Device, dessen Passphrases man vergessen oder dessen Schluessel man verloren hat NICHT (UND AUF KEINEN FALL) in einem fuer uns zu ueberlebenden Zeitraum zurueckerlangt werden koennen. BITTE vergesst eure passphases also nicht.
cryptsetup luksOpen /dev/hda3 root
Dieser Befehl oeffnet das crypto device mapping (luksOpen, erster Parameter) fuer das physikalische device (/dev/hda3, zweiter Parameter) und laesst im device node /dev/mapper/root (/dev/mapper/ + dritten Parameter) den Klartext erscheinen, als waere dieses node das eigentliche Geraet selbst. Logisch gibt es also keinen Unterschied zwischen dem Mapper Device und einer unverschluesselten Festplatte. Hier spielt das Unix-Prinzip “Alles ist eine Datei” seine Staerken aus (ich liebe es :)). Damit wir allerdings diese Aktion (die nacher auch aus dem initramfs automatisch ausgefuehrt werden muss) durchfuehren koennen, muessen wir erneut unsere Passphrase eingeben (diesmal nur einmal, schliesslich sehen wir direkt ob sie falsch war oder nicht). Haben wir uns irgendwann mal nicht vertippt, erzaehlt das cryptsetup uns welcher schluessel das denn war, mit dem wir das device entfesselt haben und setzt das Mapping in /dev/mapper/. Rein theoretisch koennten wir jetzt dort ein Dateisystem anlegen, aber das lassen wir besser. Erst probieren wir das gleiche nochmal mit dem home mapping (und ersetzen dabei den device Namen, sowie den namen des Mappings durch /dev/hda6 und ‘home’.
Damit der kernel oder besser gesagt das cryptsetup init script die Geraete und mappings, die wir brauchen wiederfindet, werden diese in der Datei /etc/crypttab (aehnlich den Dateisystemen in der /etc/fstab) verwaltet. Wir richten hier die uns wichtigen drei (ja…. tatsaechlich. Der swap wird _fast_ automagisch verschluesselt) oder mehr Eintraege an. Ich stelle alle 3 mal exemplarisch vor. Der Inhalt meiner /etc/crypttab auf der rescue-Partition schaut wie folgt aus:
root /dev/hda3 none luks,retry=3,cipher=aes-cbc-essiv:sha256
home /dev/hda6 none luks,retry=3,cipher=aes-cbc-essiv:sha256
swap /dev/hda2 /dev/random swap
Die Eintraege gestalten sich demnach im Format:
Zum keyfile und den Optionen empfehle ich einen Blick in die Manpage 5 crypttab (man 5 crypttab), wo die optionen feutlich erklaert werden. Das Keyfile sei kurz von mir erklaert. Es ist moeglich, anstatt einer Passphrase einen Schluessel aus einem Keyfile (von der beim Formatieren angegeneben Schluessellaenge) mit anzugeben. Dies empfielt sich fuer den SWAP. Da dieser eh nach dem booten unwichtig wird (mal suspend to ram ausgenommen, dass ich nie benutze) ist es moeglich, hier /dev/random einzutragen. Nicht ganz paranoide koennen hier auch /dev/urandom eintragen. Dies hat den Vorteil, dass das erstellen der 32 byte (bei 256 bit passt das) fuer den Schluessel nicht zu lange dauert. /dev/random kann manchmal SEHR langsam sein. /dev/urandom hingegen spuckt in der Regel etwa 1MB/s aus. Da unsere Rescue Partition nicht verschluesselt ist verzichten wir hier auf die angabe von Schluesselfiles. Dies wuerde, da diese gleichsam unverschluesselt und somit theoretisch fuer jedermann zugaenglich waeren unsere gesamte Arbeit unnoetig machen. Wer als Passphrase “mama” gewaehlt hat oder auf die Idee mit den keyfiles auf der rescue-Partition gekommen ist kann hier ruhigen gewissens das Lesen aufgeben. Dir fehlt in diesem Falle das noetige Mass an Verfolgungswahn ;). Auf dem verschluesselten RootFS hingegen werden wir gleich ein Schluesselfile fuer die home-Partition hinterlegen. Das erspart uns einmal Passphrase tippen und ist theoretisch genau so sicher, wie wenn die home directories auf der gleichen partition laegen wie das RootFS. Wer hier fuer das Homedir mehr Sicherheit benoetigt kann allerdings auch dann darauf verzichten.
Nun erstellen wir endlich die Dateisysteme. Bei mir fiel die Wahl fuer beide Partitionen auf ext3. Dieses Dateisystem ist ein guter Allrounder fuer solche Dinge… und ich persoenlich habe schlechte Erfahrungen mit reiserfsund xfs gemacht. Diese halten mich immer wieder davon ab die beiden nochmal auszuprobieren ;). Wir tun wieder so als seien unsere mapper-devices ganz normale Partitionen:
mkfs.ext3 /dev/mapper/root
mkfs.ext3 /dev/mapper/home
Dies erledigt alles fuer uns und kann eine weile dauern. Eine gute Gelegenheit ein Glas Wasser oder eine Flasche Bier zu holen. Fuer nen Kaffee reichts wohl nicht. Nachdem wir festgestellt haben, dass alles ok ist tragen wir das gerade getane in die /etc/fstab unseres rescue Systems ein und legen die entsprechenden Mount-Punkte an. Folgendes findet sich in meiner fstab zu den 3 dm-crypt Geraeten:
/dev/mapper/root /mnt/root ext3 defaults 0 2
/dev/mapper/home /mnt/root/home ext3 defaults 0 2
/dev/mapper/swap swap swap sw 0 0
Das mkswap, was einige vielleicht vermissen, koennen wir uns sparen. Das wird von dem cryptsetup init-Script erledigt. Zu beachten waere an dieser Stelle, dass ein bereits bestehender Eintrag auf /dev/hda2 als swap device entfernt werden sollte. Mit
mkdir /mnt/root
mount -a
mkdir /mnt/root/home
mount -a
erledigen wir alles Noetige. Es sollte normal sein, dass er nach dem ersten ‘mount -a’ noch meckert. Das tut er, da er den Pfad /mnt/root/home noch nicht finden kann. Nun fuehren wir, um das Swap Geraet zu initialisieren
/etc/init.d/cryptdisks start
swapon -a
aus. Treten hier keine Fehler auf, und zeit “free” die gewuenschte Menge an swap Speicher, so koennen wir, nachdem wir mkinitramfs mit den noetigen Informationen versorgt haben mit dem Kopieren des Root Dateisystems weitermachen. Unter
http://misc.jpoetry.net/crypto_root/cryptsetup_script.tar.gz
befindet sich ein betreutes Archiv mit 2 Scripten. Einem sog. hook-Script, dass mkinitramfs beim erstellen des initramfs sagt, was es zu noch mit in das archiv zu packen hat und ein Script, das beim booten den cryptsetup befehl ausfuehrt. Es werden nur mittels LUKS verschluesselte dm-crypt devices direkt unterstuetzt. Fuer alles weitere findet sich im Abfrage script ein Kommentar, wo es etwas einzufuegen gibt. Das Archiv mittels
tar -xzvf cryptsetup_script.tar.gz -C /
zu entpacken sollte fuer die meisten Mitmenschen genuegen. Sollten Fehler beim erstellen des initramfs auftreten, sind diese mittels der Fehlermeldungen in den 2 entpackten shell scripten leicht zu finden.
Der Befehl “cp” leistet uns nun beim “klonen” des installierten rescue-Systems gute Dienste. Oftmals liest man, dass das uebertragen von installierten Systemen nur mittels tar geschehen sollte. Das ist so nicht korrekt. cp unterstuetzt die geforderten Eigenschaften zum beibehalten von Links, special devices, Berechtigungen und so weiter ebenso. Ist /mnt/root/ und /mnt/root/home nun gemountet, kopieren wir mittels
cp -avx / /mnt/root/
cp -avx /home/* /mnt/root/home/
das gesamte installierte rescue System in unser verschluesseltes Dateisystem. Das kann einige Zeit dauern. Schliesslich werden die Daten jetzt bevor sie geschrieben werden ordendlich durch die Wurst gedreht. Wir passen nun noch einige Dinge in den Dateien /mnt/root/etc/fstab und /boot/grub/menu.lst an. In der fstab unseres spaeteren Arbeitssystems ist eigentlich nur das /mnt/root/ vor den beiden Mountpunkten fuer /dev/mapper/root und /dev/mapper/home zu entfernen. Wer moechte kann das rescue-System auf geeignete Weise in die spaetere Installation mounten, der hierfuer anzulegende Eintrag ergibt sich fast von selbst aus den Kommentaren in der Datei. Die menu.lst muss etwas gefuehlvoller angepasst werden. Hier kopieren wir einen der bestehenden Eintraege mit den Angaben fuer unser Rettungssystem (optimalerweise den aktuellsten) bis GANZ unten unter die DEBIAN AUTOMAGIC KERNELS LIST. Wer moechte kann in /boot eine kopie eines funktionierenden Kernels und eines funktionierenden initramfs anlegen und diese beispielsweise vmlinuz-rescue und initrd.img-rescue nennen. So gehen sie beim Entfernen des Kernels vom System nicht verloren (achtung ist hier den Modulen geboten, die dennoch verschwinden koennten). Ist das getan, muesste ein rescue eintrag in der menu.lst etwa so aussehen:
title Rescue System
root (hd0,0)
kernel /vmlinuz-rescue root=3,5 ro
initrd /initrd.img-rescue
boot
Weil ich etwas Probleme mit dem root dateisystem hatte, gebe ich als root= Argument die Major,Minor IDs von /dev/hda5 an. Das bootet sicherer. Ausserdem habe ich das savedefault entfernt, da ich nicht moechte, dass, wenn ich einmal das Reparatursystem gestartet habe, das gleiche wieder passiert wenn ich neu starte. Ein paar Dinge muessen noch geran werden.
Das initramfs erwartet einige erweiterte kernelparameter um daraus den cryptsetup Befehl zusammenbauen zu koennen. Diese muessen wir natuerlich JEDEM Kernel mitgeben. Innerhalb der DEBIAN AUTOMAGIC KERNELS LIST finden wir eine Zeile, die wahrscheinlich wie folgt ausschaut:
# kopt=root=/dev/hda5 ro
Dies hat der Debian Installer dort richtigerweise fuer das Rescue System hingeschrieben. Da wir aber fuer neue Kernel unser Crypto Root als rootfs mitgeben moechten geben wir hier folgenden Parameter an (der Hash (oder auch Raute (#) genannt) bleint UNBEDINGT dort stehen):
# kopt=root=/dev/mapper/root ro
Dies sagt dem Kernel, dass er unser dm-crypt device als RootFS benutzen soll. Da nun cryptsetup immernoch nicht weiss, welches echte device dorthin gemapped werden soll (wir erinnern uns daran, bei dem cryptsetup luksOpen-Aufruf /dev/hda3 angegeben zu haben) muessen wir einen weiteren Parameter hinzufuegen. Die Zeile schaut letztendlich so aus:
# kopt=root=/dev/mapper/root cryptivice=/dev/hda3 ro
Der Parameter cryptivice wird ebenfalls benutzt um festzustellen, dass der Benutzer ein dm-crypt einzuhaengen wuenscht. Hierbei handelt es sich nicht um einen Kernel-Parameter, sondern um ein Hilfskonstrukt, der von einem der Scripte, welches wir eben nach /etc/mkinitramfs entpackt haben interpretiert wird. Haben wir alles editieren beendet und die Datei gespeichert, berichtet uns
update-grub
ob alles geklappt hat. Nachfolgend erstellen wir mittels
(Hier stand mal: ‘mkinitramfs -o /boot/initrd.img-2.6.15-1-686′. Empfohlen wird jedoch:)
update-initramfs -u ALL
(jeder moege seinen aktuell laufenden Kernel da hinschreiben wo meine verwendete Version steht) das initramfs neu. Wenn hier keine Fehler auftregen fuehren wir sicherheitshalber erneut
update-grub
aus. Dies ist eigentlich nicht noetig, aber man weiss ja nie ;). Alle kurzentschlossenen tippen an dieser stelle nocheinmal “sync”.
Eben hatte ich schoneinmal angerissen, dass es sinnig sein koennte, auf der verschluesselten Root-Partition ein keyfile fuer die home-partition zu hinterlegen. Um das zu tun gehen wir wie folgt vor (wenn wir denn wollen).
Die Erstellung eines keyfiles geht mittels dd leicht von der Hand:
dd if=/dev/random of=/mnt/root/etc/keys/home.key bs=32 count=1
Der Schluessel ist erstellt. Eventuell muss man je nach Lage des Entropie-Pools ein wenig auf den Tasten Klimpern oder die Maus spazieren fuehren. Dies sort fuer genug Eingabe/Ausgabe-Daten um 32 Byte an zufalls daten zu erzeugen. Da wir moechten, dass dieser Schluessel auch ein Schloss hat, auf das er passt, benutzen wir erneut cryptsetup um den Schluessel zu unserem dm-crypt Geraet hinzuzufuegen:
cryptsetup luksAddKey /dev/hda6 /mnt/root/etc/keys/home.key
Nach eingabe der Passphrase zu dem Geraet (sicherheitshalber… man weiss ja nie wer da gerade einen schluessel hinzufuegen moechte) ist das Keyfile gueltig. Wir muessen cryptsetup und dessen initscript nur noch mitteilen, dieses auch zu benutzen. Dazu editieren wir /mnt/root/etc/crypttab entsprechend unseren Wuenschen und tragen in der Zeile von ‘home’ anstatt none /etc/keys/home.key ein. ACHTUNG. Pass auf, dass du nicht aus versehen die crypttab vom rescue-System editierst oder gar das Keyfile darin erstellst. Ist dies einmal passiert, shredde das keyfile und loesche den Schluessel mit cryptsetup aus dem device. Wie das geht verraet die manpage zu cryptsetup.
Ist das alles getan koennen wir uns an einen ersten reboot wagen. Startet das System nicht: Fehlermeldungen sammeln und in #debian-linux im euirc diskutieren. Da bin ich zu finden und kann eventuell helfen.
UPDATE: 15.2.06
Was sich sicherlich einige gefragt haben werden ist, wie sowas denn wohl performt. Ich habe dazu mal mit hdparm ein paar lese-Tests durchgefuehrt. Das rapeaesentativste Ergebnis ist folgendes:
/dev/hda:
Timing cached reads: 716 MB in 2.01 seconds = 356.81 MB/sec
Timing buffered disk reads: 74 MB in 3.05 seconds = 24.26 MB/sec/dev/mapper/root:
Timing cached reads: 700 MB in 2.00 seconds = 349.18 MB/sec
Timing buffered disk reads: 40 MB in 3.04 seconds = 13.15 MB/sec
Die Festplatte ist ein 2,5″ Notebook HDD im UDMA66 Modus ( SAMSUNG MP0804H ) auf . Fuer die noetige Cryptographie sorgt ein PIII 1200Mhz Mobile Tualatin. Der erste wert ist ohne, der 2. mit crypto. Die “cached” WErte verraten, dass der cache noch nicht verschluesselt/entschluesselt ist (da diese sich sehr stark aehneln).
–
UPDATE: 16.2.06
Gestern habe ich ein ThinkCentre E50 von Lenovo (ehemals vertrieben durch IBM) erstanden und fand die Idee irgendwie cool beim booten anstatt des oben zu sehenden blauen Crypto-Banners ein ASCII-Art IBM Logo anzuzeigen. Die neuen Scripte koennen demnach jetzt auch Theming, undzwar derart, dass man dem kernel beim booten den Parameter “crptbanner=” mitgibt. Das Script zur Erkennung des Cryptoroot mount-Wunsches, das im Endeffekt das Banner anzeigt zeigt dann, sofern vorhanden das entsprechende Banner. Bisher wird nur der Parameter ‘ibm’ unterstuetzt (wenn ich die Scripte gleich hochgeladen habe). Ein Foto gibts in der Review zum ThinkCentre an der ich gerade schreibe.
Das ThinkCentre macht mit seinem Celeron D 2.66Ghz einen Datendurchsatz von knapp 19MB/s im Lesebetrieb aus dem dm-crypt. Die HDD ansich, eine 80GB HDD aus dem Hause Seagate liest 55MB/s Rohdaten. Hier ist also immernoch der Flaschenhals am Prozessor.
Versuche, eine Hifn 7955 fuer das Crypto-API als Hardware-coprozessor dienstbar zu machen schlugen fehl. Der Entwickler des alten Linux Treiber Patches (Eugene Surovegin) erklaerte mir (auf Englisch) wie folgt:
“Der Patch ist eine Sackgasse. Du wirst zuemlich wenig erreichen, wenn du den Hifn Chip neben zeitgemaessen CPUs betreibst. Das Problem steckt im Kernel-Crypto-Layer, der synchron arbeitet. So lange da kein asynchrones Crypto im Kernel ist, sind Hardware-basierte Crypto-Beschleuniger nahezu sinnlos. Ich werde nicht mehr an diesem Patch arbeiten aus diesem speziellen Grund, daher habe ich ihn auch von meiner Webseite entfernt.”
Daraufhin habe ich alle Versuche eingestellt, das Teil sinnvoll ans laufen zu bringen ;). Danke nochmal Eugene fuer diese wirklich schnelle und ausfuehrliche Antwort. So mag ich Community-Kommunikation.
–
UPDATE: 17.02.06
Kausalitaetsupdate: Warum ueberhaupt Crypto Dateisysteme? Ich fuehre von meiner privaten Seite aus folgende 3 Gruende auf:
- Widerstand gegen Eingriff und Einblick in meine mobilen Geraete. Ich offenbare meine Daten ungerne Dritten, wenn auch nur indirekt. Jegliches Mittel um meine privaten Daten und somit meine Privatsphaere, fuer mich immernoch nutzbar vor dem Eingriff Dritter zu bewahren soll mir recht sein. Ein guter Anfang sind Crypto-Dateisysteme.
- Widerstand gegen hoehere Gewalt. Faellt die Festplatte oder ein Teil von ihr aus und ich bin gezwungen sie entweder zu vernichten oder zum Hersteller zu schicken, so gebe ich die Daten meist in beiden Faellen ungewollt und ohne die Gelegenheit einer rechnischen Vernichtung aus der Hand. Der Hersteller des Datentraegers, dem ich nicht vol lvertraue hat andere technische Mittel als ich um die Daten zu lesen. Dies ist, als Konkretisierung des ersten Punktes, unerwuenscht.
- Technischer Spieltrieb. Wie zu Anfang bereits gesagt spielt der technische Spieltrieb auch eine entscheidende Rolle. Es macht mir Spass die technischen Zusammenhaenge zwischen einem Crypto-Root-Dateisystem, dem Kernel und dem Bootvorgang, die kleinen und grossen damit verbundenen Probleme zu verstehen und aufzuloesen.
–
UPDATE: 23.02.06:
Da ein Bekannter namens ‘tums’ sehr verwirrt war ueber die Tatsache, dass zwar aus dem Rescue System heraus seine Passphrase funktionierte, beim booten aber nicht (und wir bede LANGE geraetselt haben woran das liegen koennte), habe ich die Scripte (aktuel herunterzuladen) um die loadkeys Funktionalitaet erweitert. die zu ladene Keymap (per default die, die das System auch beim booten laed) kann man unter /etc/mkinitramfs/hooks/CRYPTSETUP im header aendern. Irgendwelche Wahnsinnigen wollen bestimmt beim booten eine chinesische keymap benutzen um potentielle Angreifer zusaetzlich zu verwirren. Davon sei abgeraten. Der Standard ist bei Debian /etc/console/boottime.kmap.gz und funktioniert in der Regel.
–
UPDATE: 05.06.06:
Danke an IceBear, der mit mir in #debian-linux im euIRC das Problem fuer die Ubuntu User erleichtert hat! Ich habe das script so angepasst, dass man als “cryptivice” argument auch die major und minor des gewuenschten devices angeben kann. Dies wird dann automatisch erstellt und benutzt. Herausfinden kannst du diese Werte, indem du im laufenden System ein ls -l /dev/ machst… dort stehen dann die major und minor id durch Komma getrennt zwischen den Owner-Informationen und dem Modifikationsdatum. In meinem aktuellen Fall (/dev/sda1, major 8, minor 1) gebe ich also an: “cryptivice=8,1″. Die Zahlen sind bitte NUR durch ein Komma zu trennen.. keine Leerzeichen und keine Punkte etc bitte… Entschuldigt die lange Wartezeit
–
Danke fuers Zuhoeren und bitte fuer die Hilfe
Der Sternensucher.
* SWWFSP = Searched Web Without Finding a Similar Posting
[tags]Crypt, Crypto, root fs, cryptsetup, Debian, HowTo, dm-crypt, LUKS, mkinitramfs, initramfs, Hifn, Linux, loadkeys, keymap[/tags]
oder anderen Elementen aus $Spielerei[i] (i > 0)). In meinem Fall war das iBook ziemlich genau 1.75 Jahre alt. Im Mai waeren es 2 Jahre gewesen. Jetzt schon setzte das erste digital-Rheuma ein. Die On-Board Netzwerkloesung begann Sporadisch nicht mehr zu funktionieren… ein leises Klopfen auf den Gehaeuseteil in dem diese untergebracht war brachte in der ersten Zeit noch Linderung und das war ja eh nicht so schlimm… “Schliesslich hab ich noch AirPort”… AirPort ist ein wirklich wunderbar klingender Name fuer etwas, dass dem ambitionierten Nerd graue Haare regelrecht meterweise aus saemtlichen koerperteilen treibt, sobald dieser versucht sein liebstes Betriebssystem zu installieren. “Da gibts immernoch keine Treiber fuer das AirPort Extreme” war immer eine beliebte Antwort auf LUG-Treffen auf die Frage “Noch kein Linux drauf? Verraeter!”. Letzten endes hat sich inzwischen eine Gruppe dieses Problemes angenommen und einen inzwischen zumindest als Proof-of-Concept tauglichen Treiber zusammen-reverse-engineered, der die Stichhaltigkeit dieser Ausrede mehr und mehr schwinden laesst. AirPort Extreme rettete also meinen Tag mehrmals wenn das Stolperfallen-angebundene Netzwerkequiptment den Dienst verweigerte. Doch auch hier nagte der Zahn der Zeit. Das unverstellbare Grauen begann… Netzwerklosigkeit, Kommunikationsverlust. Der Halbtot eines Nerds tritt in dem Moment in dem die SSH-Sitzung zu seinem Lieblingsrechner alle 5 Minuten zusammenbricht. AirPort Extreme war Geschichte und zuletzt in einer Auflistung der PCI-Geraete gar nicht mehr vorhanden. “Naja… stecken wa halt mal ein USB Geraet dran…”. Diese Problemloesung half einige Tage. Im Wohnzimmer sitzend mit den Freunden in aller Welt den Abend verbringen, eine schoene Sache. Apple war immer fuer Ueberraschungen gut. Am 30. Januar als ich von der Firma nach hause kam ueberraschten sie mich mit einem Herrlichen Kurztheather. “Zwielicht” nannten Sie es, “Halbe Erblindung” nannte ich es. Fuer den interessierten Beobachter bzw. die interessierte Beobachterin stelle ich folgendes Bild in den Raum (Anmerkung: hier funktioniert AirPort gerade mal wieder durch spontanheilende Aura):
