Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic:  Caution for LUKS encrypted partitions  (Read 16186 times)

Offline melmarker

  • User
  • Posts: 2.799
    • g-com.eu
Re: Caution for LUKS encrypted partitions
« Reply #45 on: 2014/12/15, 17:28:23 »
there are pills for such fears ...
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

walter

  • Guest
Re: Caution for LUKS encrypted partitions
« Reply #46 on: 2015/01/31, 23:37:48 »
Die Upgrade Warnung für User mit verschlüsselten Festplatten ist nach wie vor aktuell.
Deshalb möchte ich meinen Workaroud, den ich mit sachkundiger Unterstützung aus dem IRC-Channel gefunden hab, hier skizzieren.

Die Ausgangssituation: Eine Festplatte mit zwei physikalischen Partitionen (sda1 und sda2). sda1 ist eine kleine, unverschlüsselte Partition, die /boot/ beherbergt und sda1 den Rest der HD. Diese Partition ist verschlüsselt mit luks. In der verschlüsselten Partition verwaltet lvm den Platz und enthält mehrere logische Volumes, u.a. root / und swap.
Mein System bootete nach einem dist-upgrade nicht mehr, ich kam nicht einmal mehr bis zur Passwortabfrage. Die Lösung des Problems hat graver am 24.10.2014 in diesem thread veröffentlicht und verweist auf die Datei /usr/share/doc/crtyptsetup/README.initramfs. Allerdings ist sein Vorgehen etwas anders als in der angegebenen Datei: Graver fügt die Zeile

Code: [Select]
cryptroot /dev/mapper/vg-crypt none luks

in die Datei /etc/crypttab ein. In der o.a. Datei README.initramfs sieht die Zeile so aus:

Code: [Select]
cryptroot /dev/sda2 none luks
Warum die von graver angegebene Zeile die richtige ist, weiß ich nicht, aber bei mir hat es funktioniert.

Ich beschreibe nun das Vorgehen, mit dem ich mein System wieder zum Laufen bekam, ausgehend von einem gebooteten Live-System.

1. Man werde in einer shell (ich hab ein tty benutzt) zum superuser:

Code: [Select]
$ su
2. Das root-Verzeichnis aus dem verschlüsselten Container einbinden:

Code: [Select]
# cryptsetup luksOpen /dev/sda2 geheim
Dabei ist geheim der Name, mit dem der verschlüsselte Container beim mapper angemeldet wird. Es wird später wichtig, dass hier der selbe Name gewählt wird wie im regulären System. Falls man diesen Namen nicht parat hat: In den Ausgaben und Fehlermeldungen beim (erfolglosen) Bootvorgang des darniederliegenden regulären Systems findet man den Namen. Ist nun die Entschlüsselung vollzogen, müssen noch die logischen Volumes aktiviert werden:

Code: [Select]
# vgscan
# vgchange -a y

Nun sollte man in /dev/mapper neben dem Cryptocontainer auch die logischen Volumes finden und mounten können.

Code: [Select]
# mount /dev/mapper/meinevolumegroup-meine_rootpartition /mnt
Eventuell müssen hier noch spezielle Optionen fürs Dateisystem angegeben werden, bei den ext-Dateisystemen ist das aber meist nicht nötig.

3. Das reguläre System mit chroot betreten
Die root-shell ins reguläre System will gut vorbereitet sein, /sys/, /proc/, /dev/ und /boot müssen eingebunden werden:

Code: [Select]
# mount /dev/sda1 /mnt/boot/
Die physikalische Bootpartition muss auch dann eingebunden werden, wenn sie nach dem Einbinden des Volumes mit dem rootverzeichnis vorhanden zu sein scheint, selbst dann wenn /boot/ bzw. /mnt/boot/ gefüllt ist/gefüllt zu sein scheint mit allem, was man in /boot/ erwartet.

Code: [Select]
# mount -o bind /dev/ /mnt/dev/
# mount -o bind /proc/ /mnt/proc/
# mount -o bind /sys/ /mnt/sys/

Nun kann man das reguläre System betreten:

Code: [Select]
# chroot /mnt/

4. Die eigentliche "Reparatur"
In die Datei /etc/crypttab trägt man die folgende Zeile ein:

Code: [Select]
cryptroot    /dev/mapper/geheim    none    luks
Der vorletzte Eintrag steht für ein mögliches keyfile, bei mir eben keins.
In der root-shell muss nur dieser eine Befehl abgesetzt werden:

Code: [Select]
# update-initramfs -c -k 3.15-1.towo-siduction-amd64
Für update-initramfs kann man -c für create oder -u für update verwenden. Bei -c versagt update-initramfs den Dienst, wenn für den Kernel schon ein entsprechendes initrd-file vorhanden ist, man müßte also das alte initrd-file verschieben/umbenennen.
Hat man bereits update-initramfs -c -k eingegeben, funktioniert die aus der shell bekannte und beliebte tab-kompletion, so dass man aus der Liste der vorhandenen Kernel auswählen kann.
Es kommt hier zu Fehlermeldungen, wenn der Container in /etc/crypttab nicht genauso heißt wie der in /dev/mapper/, weshalb beim Einhängen mit cryptsetup (s.o.) der gleiche Name wie im Standardsystem verwendet wurde.
update-initramfs gibt auch im Erfolgsfall Warnungen von mdadm aus, die aber getrost ignoriert werden können, sofern man kein raid-system oder ähnliches hat, auf jeden Fall aber, wenn man nur eine HD im Rechner hat.
Kommen also nur diese Warnungen von mdadm, dann kann man die rootshell und das Live-System verlassen und wie gewohnt das reguläre System booten.

Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
Re: Caution for LUKS encrypted partitions
« Reply #47 on: 2015/02/01, 21:07:30 »
Hi walter,

wenn in der /etc/crypttab der falsche Bezeichner bzw. das falsche Diskdevice steht, ist das klar das die LUKS-verschlüsselte Disk nicht gefunden wird. Der bei der initialen Erstellung gewählte Devicename, sowie der Pfad zum verschlüsselten Device wird zwingend von LUKS/dm-crypt benötigt.

Der Fehler ist auch einleuchtend, da nicht ein LVM-Device innerhalb der verschlüsselten Partition angegeben werden kann sondern das übergeordnete Diskdevice (/dev/sda2).

LUKS/dm-crypt ist in der logischen Schicht vor den (LVM) Devices angeordnet, sozusagen als Container für die LVM-Devices. Mit dem Kommando lsblk kann man die Hirarchie gut sehen.

Hier mein LUKS/dm-crypt System:
Code: [Select]
# lsblk
NAME               MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                  8:0    0 223,6G  0 disk 
├─sda1               8:1    0   200M  0 part  /boot
└─sda2               8:2    0 223,4G  0 part 
  └─cryptsda2      254:0    0 223,4G  0 crypt
    ├─VGsys-LVroot 254:1    0     6G  0 lvm   /
    ├─VGsys-LVvar  254:2    0     3G  0 lvm   /var
    ├─VGsys-LVhome 254:3    0     2G  0 lvm   /home
    └─VGsys-LVswap 254:4    0     2G  0 lvm   [SWAP]
sr0                 11:0    1  1024M  0 rom   
« Last Edit: 2015/02/01, 21:16:35 by bluelupo »

walter

  • Guest
Re: Caution for LUKS encrypted partitions
« Reply #48 on: 2015/02/02, 22:56:14 »
Hallo bluelupo,

je genauer ich hinschaue, desto weniger verstehe ich, warum der crypttab-Eintrag bei mir funktioniert hat bzw. gewinne den Ein druck, dass es egal ist, was in /etc/crypttab steht, hier die Ausgaben von meinem System:

Code: [Select]
walter@siductionbox:~$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931,5G  0 disk 
├─sda1                          8:1    0   150M  0 part  /boot
└─sda2                          8:2    0 931,4G  0 part 
  └─platte                    253:0    0 931,4G  0 crypt
    ├─willisvolumegroup-lvol0 253:1    0     2G  0 lvm   [SWAP]
    ├─willisvolumegroup-lvol1 253:2    0   400G  0 lvm   /mnt/crypt
    └─willisvolumegroup-siduc 253:3    0   350G  0 lvm   /
sdf                             8:80   1  14,9G  0 disk 
└─sdf1                          8:81   1  14,9G  0 part 
sr0                            11:0    1  1024M  0 rom   
walter@siductionbox:~$

und dazu (un)passend:

Code: [Select]
walter@siductionbox:~$ cat /etc/crypttab
cryptroot       /dev/mapper/cryptroot           none    luks
walter@siductionbox:~$

Laut manpage zu crypttab soll im ersten Feld der Bezeichner, also bei mir platte und im zweiten Feld das physikalische device, also bei mir /dev/sda2 stehen, also sollte die eine Zeile in  /etc/crypttab[/tt lauten

Code: [Select]
platte       /dev/sda2        none     luks

sofern ich alles richtig verstanden habe.
Ich werde, wenn ich Zeit dazu finde, verschiedene Einträge in  /etc/crypttab bzw. daraus erstellte initrds auf ihre bootfähigkeit testen.



Offline bluelupo

  • User
  • Posts: 2.068
    • BluelupoMe
Re: Caution for LUKS encrypted partitions
« Reply #49 on: 2015/02/03, 09:11:40 »
Hi walter,
hmmm, also deine crypttab dürfte so nicht funktionieren:

Code: [Select]
cryptroot       /dev/mapper/cryptroot           none    luks

Die hingegen muss funktionieren:
Code: [Select]
platte       /dev/sda2        none     luks

Teste mal und berichte. Was sagt denn "cryptsetup status cryptroot" bzw. "cryptsetup status platte"?