HowTo: LVM+Cryptsetup triple layer mit Hibernate-Fähigkeit: Unterschied zwischen den Versionen
(das proc interface wird bei der nächsten kernel version durch sys ersetzt ;)) |
Thomas (Diskussion | Beiträge) |
||
Zeile 60: | Zeile 60: | ||
Zum Schluss muss man dafür sorgen, dass das initramfs die für das booten nötigen Informationen enthält: | Zum Schluss muss man dafür sorgen, dass das initramfs die für das booten nötigen Informationen enthält: | ||
sudo update-initramfs -c -k all | sudo update-initramfs -c -k all | ||
==Konfiguration aus einem anderen System (LiveCD etc.)== | |||
Dies kann etwa nachträglich direkt nach der Installation geschehen, um das System bootbar zu machen (der Installer nimmt nicht die notwendigen Änderungen vor, die lvm und cryptsetup nutzbar machen). | |||
In diesem Fall wird man natürlich das Dateisystem, welches /etc enthält, gemountet (ggf. im laufenden System ''lvm2'' und ''cryptsetup'' installieren und dafür sorgen, dass die bereits angelegten lvm volumes unter ''/dev/mapper/'' erscheinen) und die gleiche Konfiguration wie oben eingetragen. ''update-initramfs'' lässt sich nicht direkt aufrufen, da es ja das laufende System konfigurieren will (in der Ubuntu-LiveCD meckert das Skript sogar). Statt dessen benötigt man einen ''chroot''-Trick: | |||
Man mountet das zu modifizierende System einschließlich /, /boot unter einem freien Mountpoint (hier ''/mnt''). | |||
Dann reicht man ''/dev'' und ''/proc'' in das System durch: | |||
sudo mount --bind /proc /mnt/proc | |||
sudo mount --bind /dev /mnt/dev | |||
Anschließend chrooted man in das System und erstellt das Initramfs neu: | |||
sudo chroot /mnt | |||
''(Wechsel in Rootshell im anderen System)'' | |||
update-initramfs -c -k all | |||
Um unnötige Bootzyklen zu sparen, sollte man aus dem laufenden System heraus zur Diagnose | |||
cd $TMPDIR | |||
cat /mnt/boot/initramfs-''version'' | gunzip | cpio -i | |||
aufrufen und auf das Vorhandensein einer Datei ''conf/conf.d/cryptroot'' prüfen. | |||
==Bemerkungen== | ==Bemerkungen== |
Version vom 6. Juli 2008, 18:03 Uhr
Einleitung
LVM ist ja unter anderem dafür da, sich von der Knechtschaft der Partitionierungsschemata zu befreien, um bei Bedarf Dateisysteme verkleinern oder vergrössern zu können oder weitere anzulegen. Wenn man nun
- sowohl verschlüsselte als auch unverschlüsselte Dateisysteme haben will und
- (gewissermassen) die Grenze zwischen beiden Bereichen verschieben können will,
dann bietet das hier dokumentierte Layout diese Möglichkeit. Wer LVM gar nicht kennt, mache sich zunächst mit den Grundbegriffen vertraut (siehe die Links am Ende der Seite).
Entscheidender Punkt bei diesem Layout ist, dass mittels cryptsetup nur ein einziges Cryptogerät aufgesetzt wird, aus dem alle nötigen Cryptopartitionen geschöpft werden. Auf diese Weise muss beim booten auch nur einmal ein Passwort eingegeben werden. Durch die Nutzung von LVM bereits auf der untersten Ebene kann die Zuweisung von Plattenplatz für den verschlüsselten Bereich nachträglich geändert werden, ohne eine komplizierte und gefährliche Umpartitionierungsorgie starten zu müssen (siehe aber weiter unten -- Sicherheitsaspekte).
Diese Anleitung setzt ein wenig Erfahrung in der Administration von Debian-ähnlichen Systemen voraus, nicht jeder (für erfahrene Nutzer) offensichtliche Kleinkram wird erwähnt. BACKUPS SIND ANGESAGT! Es steht nicht dabei, welche Befehle Daten überschreiben könnten.
Auf Vergrößerung/Verkleinerung von Partitionen gehe ich hier nicht näher ein und verweise auf die unten verlinkten Anleitungen. Offensichtlich gilt
- erst die Partition vergrössern, dann das Dateisystem, bzw.
- erst das Dateisystem verkleinern, dann die Partition
Wird der Cryptobereich vergrößert, sollte man sich Gedanken machen, wie man den hinzugekommenen Bereich mit hinreichend Zufall beschreibt (im Sinne des folgenden Abschnitts).
Sicherheitsaspekte
Auf kryptoanalytische Feinheiten mag/kann ich hier nicht eingehen, es sei aber Folgendes erwähnt:
Es ist üblich, den zur Ablage von verschlüsselten Daten vorgesehenen Bereich vorab mit "stark zufälligen" Daten zu beschreiben. Auf diese Weise ist es einem Angreifer, der physikalischen Zugang zur Festplatte erlangt hat, auch durch statistische Verfahren nicht möglich, Rückschlüsse auf die Intensität und den Umfang der Nutzung des Cryptobereichs zu ziehen (an die verschlüsselten Daten kommt er in jedem Fall nicht heran). Erreicht werden kann dies durch Überschreiben mit Daten aus /dev/urandom (wie unten beschrieben) oder durch Vorverschlüsseln, Überschreiben der Klartextpartition (mit Nullen) und anschliessendem neu verschlüsselt aufsetzen (so dass der alte Schlüssel verlorengeht). Letzteres ist zwar komplizierter, aber deutlich schneller.
Migrationsaspekte
Falls genügend unpartitionierter Platz auf der Platte sowie ein Slot für eine BIOS-Partition zur Verfügung steht, kann das vorhandene Layout nach und nach auf diese Lösung migriert werden. Andernfalls bzw. im Zweifel empfiehlt es sich (ggf. nach einem Backup), frisch neuzupartitionieren und dieses Layout darauf anzuwenden (was vermutlich deutlich einfacher und schneller ist).
Einrichtung
- auf der untersten Ebene sammelt man, Partition für Partition nacheinander ("fließende Migration"), alle physikalischen Partitionen (ausser einer für /boot) als lvm physical volume (pv) in einer volume group "everything" zusammen
sudo pvcreate /dev/sda2 sudo vgcreate everything /dev/sda2 sudo pvcreate /dev/sda3 sudo vgextend everything /dev/sda3
(auf einer jungfräulichen Festplatte, die man vollständig für Ubuntu nutzen möchte, würde man zunächst zwei BIOS-Partitionen anlegen, eine für /boot und eine für das einzige physical volume der volume group "everything")
- in "everything" erstellt man ein logical volume "rawcrypt", das dann mit cryptsetup aufgesetzt wird.
Beim ersten Mal ist
sudo modprobe dm-mod
nötig. Dann:
sudo lvcreate -L Größe -n rawcrypt everything sudo dd if=/dev/urandom of=/dev/mapper/everything-rawcrypt sudo cryptsetup luksFormat /dev/mapper/everything-rawcrypt sudo cryptsetup luksOpen /dev/mapper/everything-rawcrypt pvcrypt
- das mit cryptsetup auf "rawcrypt" erstellte verschlüsselte volume "pvcrypt" wird als physical volume angemeldet und als einziges pv der volume group "crypt" zugefügt:
sudo pvcreate /dev/mapper/pvcrypt sudo vgcreate crypt /dev/mapper/pvcrypt
- in "crypt" legt man seine logical volumes an, die verschlüsselt sein sollen, etwa swap:
sudo lvcreate -L Größe -n swap crypt sudo mkswap /dev/mapper/crypt-swap
Die unverschlüsselten Dateisysteme legt man direkt in logical volumes aus der volume group "everything" an. Hier gibt es keinen Grund für eine weitere Indirektion.
Konfiguration
Das swap-Gerät /dev/mapper/crypt-swap wird wie gewohnt in der /etc/fstab eingetragen, die Nutzung einer UUID ist dabei nicht notwendig.
Anscheinend ist im Header der physical volumes eingetragen, welche volume group sie konstituieren. Entsprechend weiss jede volume group natürlich von ihren logical volumes. Daher ist für lvm Nichts weiter in eine Konfigurationsdatei einzutragen.
Damit die init-Skripte von unserem cryptsetup-Mapping wissen, muss es in der /etc/crypttab eingetragen werden:
pvcrypt /dev/mapper/everything-rawcrypt none luks
Will man die Hibernate-Funktion nutzen, muss das Gerät dafür (also unser swap) in /etc/initramfs-tools/conf.d/resume eingetragen werden:
RESUME=/dev/mapper/crypt-swap
Zum Schluss muss man dafür sorgen, dass das initramfs die für das booten nötigen Informationen enthält:
sudo update-initramfs -c -k all
Konfiguration aus einem anderen System (LiveCD etc.)
Dies kann etwa nachträglich direkt nach der Installation geschehen, um das System bootbar zu machen (der Installer nimmt nicht die notwendigen Änderungen vor, die lvm und cryptsetup nutzbar machen).
In diesem Fall wird man natürlich das Dateisystem, welches /etc enthält, gemountet (ggf. im laufenden System lvm2 und cryptsetup installieren und dafür sorgen, dass die bereits angelegten lvm volumes unter /dev/mapper/ erscheinen) und die gleiche Konfiguration wie oben eingetragen. update-initramfs lässt sich nicht direkt aufrufen, da es ja das laufende System konfigurieren will (in der Ubuntu-LiveCD meckert das Skript sogar). Statt dessen benötigt man einen chroot-Trick:
Man mountet das zu modifizierende System einschließlich /, /boot unter einem freien Mountpoint (hier /mnt). Dann reicht man /dev und /proc in das System durch:
sudo mount --bind /proc /mnt/proc sudo mount --bind /dev /mnt/dev
Anschließend chrooted man in das System und erstellt das Initramfs neu:
sudo chroot /mnt (Wechsel in Rootshell im anderen System) update-initramfs -c -k all
Um unnötige Bootzyklen zu sparen, sollte man aus dem laufenden System heraus zur Diagnose
cd $TMPDIR cat /mnt/boot/initramfs-version | gunzip | cpio -i
aufrufen und auf das Vorhandensein einer Datei conf/conf.d/cryptroot prüfen.
Bemerkungen
Die Hibernate-Funktion testen kann man aus einer root-shell mittels
echo mem > /sys/power/state
oder
echo disk > /sys/power/state
VOR dem ganzen Geraffel habe ich in /etc/lvm/lvm.conf den Wert format="lvm2" gesetzt. Inwieweit das gut oder schlecht ist, konnte ich dem Internet nicht entnehmen. Ohne diese Änderung habe ich es einfach nicht ausprobiert. Mit pvscan kann man den Typ existierender physical volumes ermitteln.
Irgendwo las ich, dass für LVM physical volumes, die sich in BIOS Partitionen befinden, der Partitionstyp 0x8E vorgesehen ist.
Die gesamten lvm Tools warnen nicht davor, wenn man sie nicht mit root-Rechten bedient.
Will man später das logical volume "swap" ändern (verkleinern/vergrößern), reicht ein swapoff nicht, lvm beschwert sich, dass es immer noch in Gebrauch wäre (ich halte das für einen Bug). Auf Ubuntu in den rescue-Modus zu booten löst das Problem nicht, da dann schon der swap aktiviert ist. Man muss das Passwort für den verschlüsselten Bereich 9+6 Mal falsch eingeben -- oder man bootet gleich von einem anderen Medium.