Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout

In den letzten Beiträgen dieser Serie

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

haben wir etliche Vorüberlegungen zur Voll-Verschlüsselung eines Linux-Laptops mit SSD unter Opensuse Leap 15 angestellt. Für die anstehenden Tests muss ich noch planen, welche Partitionen das Layout meine (noch jungfräuliche) SSD prägen sollen. Ich kann hier natürlich nur einen Vorschlag vorstellen, der u.a. durch Platz für virtualisierte Gastsysteme geprägt ist und den Test von "LUKS on LVM", "LVM und LUKS" sowie Hibernation ermöglichen soll. Bei mir persönlich gibt es zudem eine Präferenz für "LUKS on LVM".

Das root-Filesystem bezeichne ich nachfolgend mit "/"-FS.

Weiterlesen

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

In den letzten Beiträgen dieser Serie

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung

hatten wir Vorüberlegungen zur Verschlüsselung eines Laptops angestellt. Wie in den früheren Beiträgen auch bezeichne ich nachfolgend sowohl Partitionen als auch LVM-Volumes als "Volumes". Wenn eine Unterscheidung notwendig ist, werde ich die explizit treffen. Für das root-Filesystem benutze ich die Abkürzung "/"-FS.

Das wichtigste Ergebnis unserer bisherigen Überlegungen war, dass wir das System, auf dem wir mit den zu schützenden Kundendaten arbeiten, voll verschlüsseln müssen. Das bedeutet, dass wir sowohl das Volume für das "/"-FS, als auch den SWAP sowie auch alle Volumes für Daten verschlüsseln. Es reicht nicht, mit Datencontainern zu arbeiten.

Unser zweites Ergebnis war: Wir sollten diesen Ansatz auf einem Virtualisierungs-System (LVM/QEMU, LXC) zur Sicherheit sowohl auf die Volumes anwenden, die der Host selbst nutzt, als auch auf alle Volumes, die von den Betriebssystemen der Gäste genutzt oder zusätzlich gemountet werden. Sprich: Auch der Virtualisierungshost muss voll-verschlüsselt werden (Root-Filesystem, Swap (!), Daten-Volumes). Es gibt zu viele Faktoren, durch die Inhalte der Gastsysteme auf Host-Filesysteme geraten können.

Wir hatten ferner diskutiert, dass im Prinzip sowohl das Host-System auf dem Laptop als auch die Gast-Systeme selbst ihren Teil zur Verschlüsselung beitragen können. Dieses Thema hat nicht zuletzt auch mit der Schichtung der Zugriffsverfahren auf Storage-Devices und Filesysteme zu tun: Jeder, der mit Linux professionell arbeitet, nutzt früher oder später LVM, um bzgl. der Anpassung der Größe von Filesystemen für Hosts und Gäste flexibel zu werden. Wie bringt man LVM mit der LUKS-Verschlüsselung zusammen? Wie stellt sich das im Fall von Virtualisierung dar?

Ein anderer für die Praxis wichtiger Punkt ist die Kompatibilität von Verschlüsselungsverfahren für Volumes mit Boot-Managern und auch systemd. Kann der unter Linux wohl hauptsächlich eingesetzte Grub2-Manager mit verschachtelten LVM/LUKS- oder LUKS/LVM-Strukturen auf Block-Devices umgehen?

Der nachfolgende Artikel geht aus grundlegender Perspektive auf diese Fragestellungen ein. Spätere Artikel widmen sich dann der praktischen Umsetzung.

Weiterlesen

cryptsetup close – not working for LVM on LUKS – device busy

I am working right now on some blog posts on a full dmcrypt/LUKS-encryption of Laptop SSDs. Whilst experimenting I stumbled across the following problem:

Normally, you would open an encrypted device by

cryptsetup open /dev/YourDevice cr-YourMapperLabel

(You have to replace the device-names and the mapper-labels by your expressions, of course). You would close the device by

cryptsetup close cr-YourMapperLabel

In my case I had created a test device "/dev/sdg3"; the mapper label was "cr-sg3". However, whenever I tried to close this special crypto-device I got the following message:

mytux:~ # cryptsetup close  cr-g3
Device cr-g3 is still in use.

Ops, had I forgotten a mount or was something operating on the filesystem inside cr-sg3 still? Unfortunately, lsof did not show anything. No process seemed to block the device ...

mytux:~ # lsof /dev/mapper/cr-g3
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1111/gvfs
      Output information may be incomplete.

But

mytux:~ # dmsetup info -C  
Name                Maj Min Stat Open Targ Event  UUID                                                                
....
cr-g3               254  16 L--w    2    1      0 CRYPT-LUKS1-Some_UUID_Info-cr-g3                  
....

Note the "2" in the Open column. Clearly, there was a count of 2 of "something" that had a firm grip on the device. I also tried

mytux:~ # dmsetup remove -f cr-g3
device-mapper: remove ioctl on cr-g3  failed: Device or resource busy
Command failed

After this trial the dmsetup table even showed an error:

mytux:~ # dmsetup table
...
cr-g3: 0 218034943 error 
...

What the hack? On the Internet I found numerous messages related to similar experiences - but no real solution.

https://www.linuxquestions.org/questions/linux-kernel-70/device-mapper-remove-ioctl-on-failed-device-or-resource-busy-4175481642/
https://serverfault.com/questions/824425/cryptsetup-cannot-close-mapped-device
https://bugzilla.redhat.com/show_bug.cgi?id=811163
https://gitlab.com/cryptsetup/cryptsetup/issues/315
https://askubuntu.com/questions/872044/mounting-usb-disk-with-luks-encrypted-partion-fails-with-a-cryptsetup-device-al

Whatever problems these guys had - I tested with other quickly created encrypted filesystems. In most cases I had no problems to close them again. It took me a while to figure out that the cause of my problems was LVM2! Stupid me! Actually, I had defined a LVM volume group "vg1" inside the encrypted partition - on purpose. The related volumes could, of course, be seen in the "/dev/mapper/" directory

mytux:~ # la /dev/mapper 
total 0
drwxr-xr-x  2 root root     440 Nov  8 15:53 .
drwxr-xr-x 28 root root   12360 Nov  8 15:53 ..
crw-------  1 root root 10, 236 Nov  8 15:46 control
lrwxrwxrwx  1 root root       8 Nov  8 16:12 cr-g3 -> ../dm-16
...
lrwxrwxrwx  1 root root       8 Nov  8 15:54 vg1-lvroot -> ../dm-17
lrwxrwxrwx  1 root root       8 Nov  8 15:53 vg1-lvswap -> ../dm-18
...

and also in "dmsetup"

mytux:~ # dmsetup info -C  
Name                Maj Min Stat Open Targ Event  UUID                                                                
.... 
vg1-lvswap          254  18 L--w    0    1      0 LVM-Some_UUID_Info
vg1-lvroot          254  17 L--w    0    1      0 LVM-Some_UUID_Info
....
cr-g3               254  16 L--w    2    1      0 CRYPT-LUKS1-Some_UUID_Info-cr-g3                  
....

So do not let yourself get confused by the fact that "lsof" may not help you to detect processes which access the crypto devices in question! It may be the kernel (with its LVM component) itself! (triggered by udev ...). This problem will always appear when you work with LVM on top of LUKS. It also explained the count of 2. The solution was simple afterwards:

mytux:~ # vgchange -a n vg1
  0 logical volume(s) in volume group "vg1" now active
mytux:~ # cryptsetup close cr-g3
mytux:~ # 

Conclusion:
Always remember to explicitly deactivate LVM volume groups that may exist on LUKS encrypted partitions before closing the crypto-device! Have a look with the commands "lvs" or "vgdisplay" first!

Addendum 12.11.2018:
The last days I have read a bit more on crypto-partitions and volumes on the Internet. I came across an article which describes the deactivation of the volume groups before closing the crypto-device clearly and explicitly:
https://blog.sleeplessbeastie.eu/2015/11/16/how-to-mount-encrypted-lvm-logical-volume/