• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] Verwendung von SSD mit LVM und dm-crypt/LUKS

gehrke

Administrator
Teammitglied
Moin *,

ich beabsichtige, meinen 7 Jahre alten PC mit einer SSD zu pimpen, insbesondere um die Startzeiten zu verbessern. Es soll eine Transcend TS64GSSD340 interne-SSD 64GB eingsetzt werden.

Ich habe schon etwas zu den speziellen Eigenheiten von SSD's gelesen, insbesondere was die mangelnde Langlebigkeit und die Klimmzüge zur Kompensation angeht. Allerdings bin ich bei einigen Informationen nicht sicher, ob die bei aktueller Hard- und Software noch gültig sind. In meinem Fall wird es sich um aktuelle Releases von OpenSUSE und Debian handeln.

Mein spezielles Partitionierungslayout basiert auf LVM und dm-crypt, was ich auch zwingend so beibehalten muss. Mir ist es wichtig, dass weitestgehend alle Daten verschlüsselt sind (also alles bis auf das Boot-Device).

Derzeit (ohne SSD) sieht das so aus:
Code:
j2:~ # lsblk
NAME                                            MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                               8:0    0  1.8T  0 disk  
├─sda1                                            8:1    0  156M  0 part  /boot
└─sda2                                            8:2    0  1.8T  0 part  
  └─cr_ata-SAMSUNG_HD204UI_XXX-part2            253:0    0  1.8T  0 crypt 
    ├─system-home                               253:1    0  1.7T  0 lvm   /home
    ├─system-os1                                253:2    0   10G  0 lvm   /
    ├─system-swap                               253:3    0    2G  0 lvm   [SWAP]
    └─system-os2                                253:4    0   10G  0 lvm

Nach meinem aktuellen Kenntnisstand würde ich jetzt versuchen, auf der neuen SSD diese Partitionen unterzubringen:
*/boot (gemeinsam genutzt)
*/swap (gemeinsam genutzt)
*/ (jeweils 1x für alle beteiligten OS)

Dabei würde ich wahrscheinlich zwei PV definieren und darauf die Partitionen verteilen:
*big: /home
*fast: /, /boot, /swap

Habt Ihr irgendwelche Hinweise vorweg?
TNX


cu, gehrke
 
OP
gehrke

gehrke

Administrator
Teammitglied
Ich habe mal versucht, das skizzierte Partitionslayout testweise in einer virtuellen Maschine mit dem Installationsprogramm von OpenSUSE 13.1 zu erzeugen.

Leider scheitere ich an der Stelle, an der ich zwar eine Volume Group /dev/system erzeugen kann, welche die beiden Physical Volumes sda1 (gesamte HD) und sdb2 (SSD ausser /boot) enthält. Aber ich sehe keine Möglichkeit, diese gesamte VG 'system' einheitlich zu verschlüsseln. Verschlüsselung wird mir nur bei Partitionen oder LVs angeboten. Das hätte zur Folge, dass ich keinen gemeinsamen Verbund habe und die Passphrase beim Start zweimal eingeben müsste.

Wie geht denn das???
TNX
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
Aber ich sehe keine Möglichkeit, diese gesamte VG 'system' einheitlich zu verschlüsseln. Verschlüsselung wird mir nur bei Partitionen oder LVs angeboten. Das hätte zur Folge, dass ich keinen gemeinsamen Verbund habe und die Passphrase beim Start zweimal eingeben müsste.

Eine Lösung für das Problem (analog https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_Entire_System#LUKS_on_LVM) sieht so aus, dass zwar zwei unabhängige Crypt-Container verwendet werden, der Schlüssel für den zweiten aber auf dem ersten hinterlegt wird. Beim Booten wird hier nur einmalig für den ersten die Passphrase abgefragt. Ich habe das mal in einer VM mit OpenSUSE 13.1 getestet.

Zuerst habe ich mit dem Installationsprogramm die Struktur mit den zwei Containern aufgebaut:
Code:
localhost:~ # lsblk
NAME                                               MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                                  8:0    0   23G  0 disk  
├─sda1                                               8:1    0  509M  0 part  /boot
└─sda2                                               8:2    0 22.5G  0 part  
  └─cr_ata-VBOX_HARDDISK_VBeadfccbc-d27bbada-part2 253:0    0 22.5G  0 crypt 
    ├─fast-os1                                     253:1    0  9.5G  0 lvm   /
    ├─fast-os2                                     253:2    0  9.5G  0 lvm   
    └─fast-swap                                    253:3    0  3.5G  0 lvm   [SWAP]
sdb                                                  8:16   0    5G  0 disk  
└─sdb1                                               8:17   0    5G  0 part  
  └─cr_ata-VBOX_HARDDISK_VBafd1fff5-43bac287-part1 253:4    0    5G  0 crypt 
    └─big-home                                     253:5    0    5G  0 lvm   /home
sr0                                                 11:0    1  4.3G  0 rom
Auf jeder Partition liegt ein Crypt-Container und darin ein PV:
Code:
localhost:~ # pvs
  PV                                                         VG   Fmt  Attr PSize  PFree
  /dev/mapper/cr_ata-VBOX_HARDDISK_VBafd1fff5-43bac287-part1 big  lvm2 a--   4.98g    0 
  /dev/mapper/cr_ata-VBOX_HARDDISK_VBeadfccbc-d27bbada-part2 fast lvm2 a--  22.50g 4.00m

localhost:~ # pvdisplay
  --- Physical volume ---
  PV Name               /dev/mapper/cr_ata-VBOX_HARDDISK_VBafd1fff5-43bac287-part1
  VG Name               big
  PV Size               4.98 GiB / not usable 4.00 MiB                                                                                         
  Allocatable           yes (but full)                                                                                                         
  PE Size               4.00 MiB                                                                                                               
  Total PE              1275                                                                                                                   
  Free PE               0                                                                                                                      
  Allocated PE          1275                                                                                                                   
  PV UUID               ZKHHwj-GaER-QIGn-L0e3-tql6-oDEd-nfmurw                                                                                 
                                                                                                                                               
  --- Physical volume ---                                                                                                                      
  PV Name               /dev/mapper/cr_ata-VBOX_HARDDISK_VBeadfccbc-d27bbada-part2                                                             
  VG Name               fast                                                                                                                   
  PV Size               22.50 GiB / not usable 4.00 MiB                                                                                        
  Allocatable           yes                                                                                                                    
  PE Size               4.00 MiB                                                                                                               
  Total PE              5759                                                                                                                   
  Free PE               1                                                                                                                      
  Allocated PE          5758                                                                                                                   
  PV UUID               zi0xHX-aa7C-sZF0-Ukyb-sIPv-VrjV-CK4GBc

Die logischen Laufwerke (LV):
Code:
localhost:~ # lvs
  LV   VG   Attr      LSize Pool Origin Data%  Move Log Copy%  Convert
  home big  -wi-ao--- 4.98g                                           
  os1  fast -wi-ao--- 9.50g                                           
  os2  fast -wi-a---- 9.50g                                           
  swap fast -wi-ao--- 3.49g
Bis hierhin geht noch alles out-of-the-box mit dem Installer, allerdings werden nun beim Booten für beide Container die Passphrases abgefragt.

Um die Eingabe der Passphrase für den zweiten Crypt-Container zu umgehen, wird ein Schlüssel in einer Datei erzeugt, welcher in einem zweiten Slot (LUKS kann AFAIK max. 8 Slots für Zugänge verwalten) als gültiger Schlüssel festgelegt wird. Anschließend wird dieses Key-File unter /etc/crypttab eingetragen, wodurch der Container beim Booten freigeschaltet wird.

Erzeugung des Keys:
Code:
localhost:~ # mkdir -p -m 700 /etc/luks-keys
localhost:~ # dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256
256+0 records in                                                                                                                               
256+0 records out                                                                                                                              
256 bytes (256 B) copied, 178.612 s, 0.0 kB/s

Diese Schlüssel wird dem LUKS-Container in einem freien Slot hinzugefügt, wofür eine gültige Passphrase notwendig ist.
Code:
localhost:~ # cryptsetup luksAddKey /dev/sdb1 /etc/luks-keys/home
Enter any passphrase:

Überprüfung: Jetzt sollten zwei Slots belegt sein
Code:
localhost:~ # cryptsetup luksDump /dev/sdb1
LUKS header information for /dev/sdb1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      b2 29 48 40 1c 3f d2 30 46 29 3c c8 64 de eb f7 92 90 d6 79 
MK salt:        9e e6 39 a3 ab c6 12 3d 0c 11 2b ed 0d da 1d 36 
                2e 44 b6 4c 37 16 39 6f 81 b7 18 7a f5 ae 8d 85 
MK iterations:  41875
UUID:           2ad7c498-11a2-4ed0-b881-b119fa960bc7

Key Slot 0: ENABLED
        Iterations:             167539
        Salt:                   36 1f a7 c0 8f a1 33 6d 35 b0 8e 45 d1 85 95 75 
                                09 12 d4 95 ef d1 3a b3 38 fe 2f e9 c7 ab bb d5 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             177777
        Salt:                   20 19 ee 90 bf 59 a2 15 9e 3e f3 af 89 2e bb 98 
                                6e 30 96 2a c3 15 1d 73 42 a7 9d 98 24 49 f6 e4 
        Key material offset:    264
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Damit ist der Zugriff auf den Container mithilfe des Key-Files gegeben.

Abschließend wird dieses Key-File in der Datei /etc/crypttab eingetragen, welche beim Booten ausgelesen wird:
Code:
localhost:~ # cat /etc/crypttab
cr_ata-VBOX_HARDDISK_VBeadfccbc-d27bbada-part2 /dev/disk/by-id/ata-VBOX_HARDDISK_VBeadfccbc-d27bbada-part2 none       none                     
cr_ata-VBOX_HARDDISK_VBafd1fff5-43bac287-part1 /dev/disk/by-id/ata-VBOX_HARDDISK_VBafd1fff5-43bac287-part1 none       none                     
localhost:~ # vi /etc/crypttab                                                                                                              
localhost:~ # cat /etc/crypttab                                                                                                                
cr_ata-VBOX_HARDDISK_VBeadfccbc-d27bbada-part2 /dev/disk/by-id/ata-VBOX_HARDDISK_VBeadfccbc-d27bbada-part2 none       none                     
cr_ata-VBOX_HARDDISK_VBafd1fff5-43bac287-part1 /dev/disk/by-id/ata-VBOX_HARDDISK_VBafd1fff5-43bac287-part1 /etc/luks-keys/home       none

Diese Vorgehensweise habe ich ich getestet und sie funktioniert soweit.

Als vorteilhaft sehe ich an, dass es hier zwei unabhängige Einheiten gibt. Wenn einer davon stirbt, ist der andere weiterhin verwendbar.

Nachteilig ist, dass in dieser Konstellation der Schlüssel für den zweiten Crypt-Container offen im Dateisystem des ersten liegt. Zwar ist er nur von root lesbar und ist geschützt durch die Verschlüsselung des ersten Containers, aber solange der online ist, könnte er möglicherweise gestohlen werden.
Das erscheint mir doch recht riskant zu sein. So ganz bin ich damit noch nicht zufrieden. Möglicherweise könnte man das Key-File verschlüsseln mit der Passphrase für den ersten LUKS-Container, aber mir ist derzeit kein Mechanismus bekannt, der beim Booten diesen zur Entschlüsselung verwendet!?!
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
Abschließend wird dieses Key-File in der Datei /etc/crypttab eingetragen, welche beim Booten ausgelesen wird:
[...]
Nachteilig ist, dass in dieser Konstellation der Schlüssel für den zweiten Crypt-Container offen im Dateisystem des ersten liegt. Zwar ist er nur von root lesbar und ist geschützt durch die Verschlüsselung des ersten Containers, aber solange der online ist, könnte er möglicherweise gestohlen werden.
Das erscheint mir doch recht riskant zu sein. So ganz bin ich damit noch nicht zufrieden. Möglicherweise könnte man das Key-File verschlüsseln mit der Passphrase für den ersten LUKS-Container, aber mir ist derzeit kein Mechanismus bekannt, der beim Booten diesen zur Entschlüsselung verwendet!?!

Ich bin hier noch nicht wirklich weiter gekommen. Meine Recherchen ergaben, dass es wohl bei Debian hierfür eine Lösung geben soll mit einem Script, welches in der crypttab referenziert werden kann:
Code:
/lib/cryptsetup/scripts/decrypt_derived
Unter OpenSUSE habe ich aber bislang nichts vergleichbares gefunden. Hat jemand einen Tipp???
TNX
 
OP
gehrke

gehrke

Administrator
Teammitglied
Ich habe jetzt ein entsprechendes Layout via Neuinstallation umgesetzt:

Code:
j2:~ # lsblk
NAME                                              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                                 8:0    0 59.6G  0 disk  
├─sda1                                              8:1    0    1G  0 part  /boot
└─sda2                                              8:2    0 58.6G  0 part  
  └─cr_ata-TS64GSSD340_201401xxx-part2 253:0    0 58.6G  0 crypt 
    ├─fast-os1                                    253:1    0 18.2G  0 lvm   /
    ├─fast-os2                                    253:2    0 18.2G  0 lvm   
    ├─fast-os3                                    253:3    0 18.2G  0 lvm   
    └─fast-swap                                   253:4    0    4G  0 lvm   [SWAP]
sdb                                                 8:16   0  1.8T  0 disk  
└─sdb1                                              8:17   0  1.8T  0 part  
  └─cr_ata-SAMSUNG_HD204UI_xxx-part1   253:5    0  1.8T  0 crypt 
    └─big-home                                    253:6    0  1.8T  0 lvm   /home

Hat soweit auch ganz gut funktioniert, aber der absolute Performance-Boost hat sich noch nicht eingestellt. Einige Dinge laufen etwas flüssiger, aber riesig ist der Unterschied nun wirklich nicht. Optimierungen irgendwelcher Art habe ich noch nicht gemacht, einfach nur Standard-Installation.

Nominell:
Code:
j2:~ # hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   4546 MB in  2.00 seconds = 2273.35 MB/sec
 Timing buffered disk reads: 578 MB in  3.00 seconds = 192.37 MB/sec

j2:~ # hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   4750 MB in  2.00 seconds = 2374.91 MB/sec
 Timing buffered disk reads: 248 MB in  3.01 seconds =  82.32 MB/sec
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
Hat soweit auch ganz gut funktioniert, aber der absolute Performance-Boost hat sich noch nicht eingestellt. Einige Dinge laufen etwas flüssiger, aber riesig ist der Unterschied nun wirklich nicht. Optimierungen irgendwelcher Art habe ich noch nicht gemacht, einfach nur Standard-Installation.
Hauptsächlich war es das Warten beim Booten auf den DHCP-Server, welches durch Konfigurationsänderungen auf dem Client behoben wurde (siehe http://forum.linux-club.de/viewtopic.php?f=86&t=119040). Jetzt bootet die alte Büchse echt flott.

Offen bleibt aber weiterhin das Problem, das der zweite Key unverschlüsselt auf der SSD liegt. Dort ist er gefährdet, solange der erste LUKS-Container online ist. Dafür brauche ich weiterhin eine Lösung.
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
Offen bleibt aber weiterhin das Problem, das der zweite Key unverschlüsselt auf der SSD liegt. Dort ist er gefährdet, solange der erste LUKS-Container online ist. Dafür brauche ich weiterhin eine Lösung.
So, zwei Jahre später habe ich dafür eine Lösung, sogar out-of-the-box. Zumindest bei aktuellen Systemen wird automatisch der für die erste Disk eingegebene Key auch für nachfolgende LUKS-Container ausprobiert. Wenn der dort auch passt, ist das Thema schon erledigt. Damit entfällt das riskante unverschlüsselte Speichern des zweiten Keys.

Initial so gesehen bei Debian und getestet mit Fedora 23. Möglicherweise geht das 'schon immer' so und ich habe es nur nicht gewusst.
 
Oben