Category Archives: Security und Security-Tools

Shrinking an encrypted partition with LVM on LUKS

Posted on by

Whilst experimenting with with encrypted partitions I wanted to shrink an “oversized” LUKS-encrypted partition. I was a bit astonished over the amount of steps required; in all the documentations on this topic some points were missing. In addition I also stumbled over the mess of GiB and GB units used in different tools. Safety considerations taking into account the difference are important to avoid data loss. Another big trap was the fact that the tool “parted” expects an end point on the disk given in GB when resizing. I nearly did it wrong.

Otherwise the sequence of steps described below worked flawlessly in my case. I could reboot the resized root-system enclosed in the encrypted partition after having resized everything.

I list up the necessary steps below in a rather brief form, only. I warn beginners: This is dangerous stuff and the risk for a full data loss not only in the partition you want to resize is very high. So, if you want to experiment yourself – MAKE A BACKUP of the whole disk first.

Read carefully through the steps before you do anything. If you are unsure about what the commands mean and what consequences they have do some research on the Internet ahead of any actions. Likewise in case of trouble or error messages.

You should in general be familiar with partitioning, LVM, dm-crypt and LUKS. I take no responsibility for any damage or data loss and cannot guarantee the applicability of the described steps in your situation – you have been warned.

My disk layout

My layout of the main installation was

SSD –> partition 3 –> LUKS –> LVM –> Group “vg1” –> Volume “lvroot” –> ext4 fs [80 GiB]

SSD –> partition 3 –> LUKS –> LVM –> Group “vg1” –> Volume “lvswap” –> swap fs [2 GiB]

The partition had a size around 104 GiB before shrinking. “lvroot” included a bootable root filesystem of 80 GiB in size. The swap volume (2 GiB) will later help us to demonstrate that shrinking may lead to gaps between logical LVM volumes. We shall shrink the file system, its volume, the volume group and also the encrypted the partition in the end.

In my case I could attach the disk in question to another computer where I performed the resizing operation. If you have just one computer available use a Live System from an USB stick or a DVD. Or boot another Linux installation available on one of the other disks of your system. [I recommend to always have a second small bootable installation available on one of the disks of your PC/laptop besides the main installation for daily work :-). This second installation can reside in an encrypted LVM volume (LUKS on LVM), too. It may support administration and save your life one day in case your main installation becomes broken. There you may also keep copies of the LUKS headers and keyfiles …].

Resizing will be done by a sequence of 16 steps – following the disk layout in reverse order as shown above; i.e. we proceed with first resizing the filesystem, then taking care about the LVM layout and eventually changing the partition size.

You open an encrypted partition with LVM on LUKS just as any dm-crypt/LUKS-partition by

cryptsetup open /dev/YOUR_DEVICE… MAPPING-Name

For the mapping name I shall use “cr-ext“. Note that manually closing the encrypted device requires to deactivate the volume groups in the kernel first; in our case

vgchange -a n vg1;
cryptsetup close cr-ext

Otherwise you may not be able to close your device.

A sequence of 16 steps ….

Let us now go through the details of the required steps – one by one.

Step 1: Get an overview over your block devices

You should use

lsblk

In my case the (external) disk appeared as “/dev/sdg” – the encrypted partition was located on “/dev/sdg3”.

***********

Step 2: Open the encrypted partition

cryptsetup open /dev/sdg3 cr-ext

Check that the mapping is done correctly by “la /dev/mapper” (la = alias for “ls -la”). Watch out not only for the “cr-ext”-device, but also for LVM-volumes inside the encrypted partition. They should appear automatically as distinct devices.

***********

Step 3: Get an overview on LVM structure

Use the following standard commands:

pvdisplay
vgdisplay
lvdisplay

“pvdisplay”/”vgdisplay” should show you a PV device “/dev/mapper/cr-ext” with volume group “vg1” (taking full size). If the volume groups are not displayed you may need to make them available by “vgchange –available y” (see the man pages).

“lvdisplay” should show you the logical volumes consistently with the entries in “/dev/mapper”. Note: “lvdisplay” actually shows the volumes as “/dev/vg1/lvroot”, whereas the link in “/dev/mapper” includes the name of the volume group: “/dev/mapper/vg1-lvroot”. In my case the original size of “lvroot” was 80 GiB and the size of the swap “lvswap” was 2 GiB.

***********

Step 4: Check the integrity of the filesystem

Use fsck: 

mytux:~ # fsck /dev/mapper/vg1-lvroot 
fsck from util-linux 2.31.1
e2fsck 1.43.8 (1-Jan-2018)
/dev/mapper/vg1-lvroot: clean, 288966/5242880 files, 2411970/20971520 blocks

The filesystem should be clean. Otherwise run “fsck -f” – and answer the questions properly. “fsck” in write mode should be possible as we have not mounted the filesystem. We avoid doing so throughout the whole procedure.

***********

Step 5: Check the physical block size of the filesystem and the used space within the filesystem

Use “fdisk -l” to get the logical and physical block sizes

Disk /dev/mapper/vg1-lvroot: 80 GiB, 85899345920 bytes, 167772160 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Use tunefs to get some block information:

tune2fs -l /dev/mapper/vg1-lvroot

to get the number of total blocks (20971520), blocksize (4096) and free blocks (18559550) – in my case : 

Total = 85899345920 Bytes = 85 GB = 80 GiB 
free  = 76019916800 Bytes = 76 GB = 70,8 GiB

If you mount df -h may will show you less available space due to a 5% free limit set => 67G. So, not much space was occupied by my (Opensuse) test installation inside the volume.

***********

Step 6: Plan the reduced volume and filesystem sizes ahead – perform safety and limit considerations

Plan ahead the new diminished size of the LVM-Volume (“lvroot”). Let us say, we wanted 60G instead of the present 80G. Then we must reduce the filesystem [fs] size even more and use a safety-factor of 0.9 => 54G. I stress:

Make the filesystem size at least 10% smaller than the planned logical volume size!

Why this precaution? There may be a difference for the meaning of “G” for the use of the resize commands: “resize2fs” and the “lvresize“. It could be “GB” or “GiB” in either case.

Have a look into the man pages. This difference is really dangerous! What would be the worst case that could happen? We resize the filesystem in GiB and the volume size in GB – then the volume size would be too small.

So, let us assume that “lvresize” works with GB – then the 60G would correspond to 60 * 1024 * 1000 * 1000 Bytes = 6144000000 Bytes. Assume further that “resize2fs” works with GiB instead. Then we would get 54 * 1024 * 1024 * 1024 Bytes = 57982058496 Bytes. We would still have a reserve! We would potentially through away disk space;
however, we will compensate for it afterwards (see below).

If you believe what the present man-pages say: For “resize2fs” the “size” parameter can actually be given in units of “G” – but internally GiB are used. For “lvresize”, however, the situation is unclear.

In addition we have to check the potential reduction range against the already used space! In our case there is no problem (see step 5). However, how far could you maximally shrink if you needed to?

Minimum-consideration: Give the 10 GiB used according to step 5 a good 34% on top. (We always want a free space of 25%). Multiply by a factor of 1.1 to account for potential GB-GiB differences => 15 GiB. This is a rough minimum limit for the minimum size of the filesystem. The logical volume size should again be larger by a factor of 1.1 at least => 16.5 GB.

Having calculated your minimum you choose your actual shrinking size above this limit: You reduce the volume size by something between the 80 GiB and the 16.5 GiB. You set a number – let us say 60 GiB – and then you reduce the filesystem by a factor 0.9 more => 54 GB.

***********

Step 7: Shrink the filesystem

Check first that the fs is unmounted! Otherwise you may run into trouble: 

mytux:~ # resize2fs /dev/mapper/vg1-lvroot 60G
resize2fs 1.43.8 (1-Jan-2018)
Filesystem at /dev/mapper/vg1-lvroot is mounted on /mnt2; on-line resizing required
resize2fs: On-line shrinking not supported

So unmount, run fsck again and then resize: 

maytux:~ # umount /mnt2
mytux:~ # e2fsck -f /dev/mapper/vg1-lvroot
e2fsck 1.43.8 (1-Jan-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vg1-lvroot: 288966/5242880 files (0.2% non-contiguous), 2411970/20971520 blocks
mytux:~ # resize2fs /dev/mapper/vg1-lvroot 54G
resize2fs 1.43.8 (1-Jan-2018)
Resizing the filesystem on /dev/mapper/vg1-lvroot to <pre style="padding:8px;"> (4k) blocks.
The filesystem on /dev/mapper/vg1-lvroot is now 14155776 (4k) blocks long.
mytux:~ # e2fsck -f /dev/mapper/vg1-lvroot
e2fsck 1.43.8 (1-Jan-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vg1-lvroot: 288966/3538944 files (0.3% non-contiguous), 2304043/14155776 blocks

***********

Step 8: Shrink the logical volume

We use “lvreduce” to resize the LVM volume; the option parameter “L” together with a “size” determines how big the volume will become. [ Note that there is a subtle difference if you provide the size with a negative “-” sign! See the man page for the difference!] 

mytux:~ # lvreduce -L 60G /dev/mapper/vg1-lvroot 
  WARNING: Reducing active logical volume to 60.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vg1/lvroot? [y/n]: y
  Size of logical volume vg1/lvroot changed from 80.00 GiB (20480 extents) to 60.00 GiB (15360 extents).
  Logical volume vg1/lvroot successfully resized.
mytux:~ #

Hey, we worked in GiB – good to know!

***********

Step 9: Extend the fs to the volume size again

We compensate for the lost space of almost 6 GiB: 

mytux:~ # resize2fs /dev/mapper/vg1-lvroot 
resize2fs 1.43.8 (1-Jan-2018)
Resizing the filesystem on /dev/mapper/vg1-lvroot to 15728640 (4k) blocks.
The filesystem on /dev/mapper/vg1-lvroot is now 15728640 (4k) blocks long.

Run gparted to get an overview over the present situation.

***********

Step 10: Check for gaps between the volumes of your LVM volume group

Besides the LVM volume for the OS and data related filesystem we had a swap volume, too! As we have not changed it there should be a gap between the volumes now – and indeed: 

mytux:~ # pvs -v --segments /dev/mapper/cr-ext
    Wiping internal VG cache
    Wiping cache of LVM-capable devices
  PV                 VG  Fmt  Attr PSize   PFree  Start SSize LV     Start Type   PE Ranges                     
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g     0 15360 lvroot     0 linear /dev/mapper/cr-ext:0-15359    
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g 15360  5120            0 free                                 
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g 20480   512 lvswap     0 linear /dev/mapper/cr-ext:20480-20991
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g 20992  5623            0 free                                 
mytux:~ #

Now, to close the gap we can move the second volume. This requires multiple trials with “pvmove –alloc anywhere”.

Note the information “/dev/mapper/cr-ext:20480-20991” and use this exactly in “pvmove”: 

mytux:~ # pvmove --alloc anywhere /dev/mapper/cr-ext:20480-20991
  /dev/mapper/cr-ext: Moved: 0.20%
  /dev/mapper/cr-ext: Moved: 100.00%
mytux:~ # pvs -v --segments /dev/mapper/cr-ext                  
    Wiping internal VG cache
    Wiping cache of LVM-capable devices
  PV                 VG  Fmt  Attr PSize   PFree  Start SSize LV     Start Type   PE Ranges                     
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g     0 15360 lvroot     0 linear /dev/mapper/cr-ext:0-15359    
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g 15360  5632            0 free                                 
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g 20992   512 lvswap     0 linear /dev/mapper/cr-ext:20992-21503
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g 21504  5111            0 free

You may have to apply “pvmove” several times, but each time with the new changed position parameters – be careful !!! (Are your backups OK???).

This may give you some seemingly erratic movements, but eventually, you should see a continuous alignment: 

mytux:~ # pvmove --alloc anywhere /dev/mapper/cr-ext:20992-21503
  /dev/mapper/cr-ext: Moved: 1.76%
  /dev/mapper/cr-ext: Moved: 100.00%
mytux:~ # pvs -v --segments /dev/mapper/cr-ext
    Wiping internal VG cache
    Wiping cache of LVM-capable devices
  PV                 VG  Fmt  Attr PSize   PFree  Start SSize LV     Start Type   PE Ranges                     
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g     0 15360 lvroot     0 linear /dev/mapper/cr-ext:0-15359    
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g 15360   512 lvswap     0 linear /dev/mapper/cr-ext:15360-15871
  /dev/mapper/cr-ext vg1 lvm2 a--  103.96g 41.96g 15872 10743            0 free                                 
mytux:~ #

***********

Step 11: Resize/reduce the physical LVM

After having aligned the volumes of the volume group vg1 we now can resize the physical LVM volume supporting the vg1 group. We use “pvresize” for this purpose. “pvresize” works in GiB – but its parameters just have a “G”.
In my example I shrank the physical LVM area down to 80G = 80GiB. This left more than enough space for my two LVM volumes. 

mytux:~ # pvresize --setphysicalvolumesize 80G /dev/mapper/cr-ext  
/dev/mapper/cr-ext: Requested size 80.00 GiB is less than real size 103.97 GiB. Proceed?  [y/n]: y
  WARNING: /dev/mapper/cr-ext: Pretending size is 167772160 not 218034943 sectors.
  Physical volume "/dev/mapper/cr-ext" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
mytux:~ # pvdisplay
....   
  --- Physical volume ---
  PV Name               /dev/mapper/cr-ext
  VG Name               vg1
  PV Size               80.00 GiB / not usable 3.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              20479
  Free PE               4607
  Allocated PE          15872
  PV UUID               eFf9we-......

Again, we obviously worked in GiB – good.

***********

Step 12: Set new size of the encrypted region

It is disputed whether this step is required. LUKS never registers the size of the encrypted area. However, if you had an active mounted partition … In our case, I think the step is not required, but …..

“cryptsetup resize” wants sectors as a size unit. We have to calculate a bit again based on the amount of sectors (each with 512 Byte; see below) used: 

mytux:~ # cryptsetup status cr-ext
/dev/mapper/cr-ext is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/sdg3
  sector size:  512
  offset:  65537 sectors
  size:    218034943 sectors
  mode:    read/write

We have to determine the new size in sectors to reduce the size of the LUKS area. I chose:
185329702 blocks (rounded up) – this corresponds to around 88.4 GiB; according to our 10% safety rule this should be sufficient. 

mytux:~ # cryptsetup -b 185329702 resize cr-ext
mytux:~ # cryptsetup status cr-ext             
/dev/mapper/cr-ext is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/sdg3
  sector size:  512
  offset:  65537 sectors
  size:    185329702 sectors
  mode:    read/write

***********

Step 13: Reduce the size of the physical partition – a pretty scary step!

This is one of the most dangerous steps. And irreversible … Interestingly, gparted will not let you do a resize. Yast’s partitioner allows for it after several confirmations. I used “parted” in the end.

But especially with parted you have to be extremely careful – parted expects a partition’s end position in GB. This means that to calculate the resulting size correctly you must also look at the partition’s starting position. In the end it is the difference that counts. Read the man pages and have a look into other resources. 

mytux:~ # parted /dev/sdg
GNU Parted 3.2
Using /dev/sdg
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: USB 3.0 (scsi)
Disk /dev/sdg: 512GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  16.8MB  15.7MB               primary  bios_grub
 2      33.6MB  604MB   570MB                primary  boot, esp
 3      604MB   112GB   112GB                primary  legacy_boot, msftdata
 4      291GB   312GB   21.5GB                        lvm
 5      312GB   314GB   2147MB               primary  msftdata

(parted) resizepart 
Partition number? 3                                                       
End?  [112GB]? 89GB                                                       
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? Yes                                                               
(parted) print      
Model: USB 3.0 (scsi)
Disk /dev/sdg: 512GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  16.8MB  15.7MB               primary  bios_grub
 2      33.6MB  604MB   570MB                primary  boot, esp
 3      604MB   89.0GB  88.4GB               primary  legacy_boot, msftdata
 4      291GB   312GB   21.5GB                        lvm
 5      312GB   314GB   2147MB               primary  msftdata

(parted) q                                                                
Information: You may need to update /etc/fstab.

As you see: We end up with a size of 88.4 GB and NOT 89 GB !!!

In addition we shall see in a second that the GB are NOT GiB here! So our safety factor is really important to get close to the aspired 80 GiB.

***********

Step 14: Set new size of the encrypted region

As we have some space left now in the partition we can enlarge the encryption area and later also the PV size to the possible maximum.
First, we set back the size of the encryption area to the full partition size; though not required in our case – it does not harm: 

mytux:~ # cryptsetup  resize cr-ext
mytux:~ # cryptsetup status cr-ext
/dev/mapper/cr-ext is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/sdg3
  sector size:  512
  offset:  65537 sectors
  size:    172582959 sectors
  mode:    read/write

***********

Step 15: Reset the PV size to the full partition size

We use “pvsize” again without any size parameter. The volume group will follow automatically.

mytux:~ # pvresize  /dev/mapper/cr-ext    
  Physical volume "/dev/mapper/cr-ext" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized 
mytux:~ # pvdisplay
...  
  --- Physical volume ---
  PV Name               /dev/mapper/cr-ext
  VG Name               vg1
  PV Size               82.29 GiB / not usable 1000.50 KiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              21067
  Free PE               5195
  Allocated PE          15872
  PV UUID               eFf9we-......
..
mytux:~ # vgdisplay
....
  --- Volume group ---
  VG Name               vg1
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  16
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               82.29 GiB
  PE Size               4.00 MiB
  Total PE              21067
  Alloc PE / Size       15872 / 62.00 GiB
  Free  PE / Size       5195 / 20.29 GiB
  VG UUID               dZakZi-......

Our logical volumes are alive, too, and have the right size. 

mytux:~ # lvdisplay
...
  --- Logical volume ---
  LV Path                /dev/vg1/lvroot
  LV Name                lvroot
  VG Name                vg1
  LV UUID                5cDvmf-......
  LV Write Access        read/write
  LV Creation host, time install, 2018-11-06 15:33:52 +0100
  LV Status              available
  # open                 0
  LV Size                60.00 GiB
  Current LE             15360
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     1024
  Block device           254:17
   
  --- Logical volume ---
  LV Path                /dev/vg1/lvswap
  LV Name                lvswap
  VG Name                vg1
  LV UUID                lCU75L-......
  LV Write Access        read/write
  LV Creation host, time install, 2018-11-06 18:21:11 +0100
  LV Status              available
  # open                 0
  LV Size                2.00 GiB
  Current LE             512
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     1024
  Block device           254:18

And: 

mytux:~ # pvs -v --segments /dev/mapper/cr-ext
    Wiping internal VG cache
    Wiping cache of LVM-capable devices
  PV                 VG  Fmt  Attr PSize  PFree  Start SSize LV     Start Type   PE Ranges                     
  /dev/mapper/cr-ext vg1 lvm2 a--  82.29g 20.29g     0 15360 lvroot     0 linear /dev/mapper/cr-ext:0-15359    
  /
dev/mapper/cr-ext vg1 lvm2 a--  82.29g 20.29g 15360   512 lvswap     0 linear /dev/mapper/cr-ext:15360-15871
  /dev/mapper/cr-ext vg1 lvm2 a--  82.29g 20.29g 15872  5195            0 free

We also check with gparted:

Everything is fortunately Ok!

***********

Step 16: Closing and leaving the encrypted device 

mytux:~ # vgchange -a n vg1

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

Conclusion

Shrinking an encrypted Luks partition which is used as a physical LVM volume and contains a LVM group with volumes is no rocket science. One has to apply the necessary shrinking steps starting from the innermost objects to the containers around them. I.e, we start shrinking the LVM volumes first, then take care of the LVM volume group and the LVM PV. Eventually, we deal with the encryption area and the hard disk partition.

During each step one has to be careful regarding the tools and sizing units: For each tool it has to be clarified whether it works in GB or GiB. Safety margins during each shrinking step have to be calculated and to be taken into account.

Links

https://www.rootusers.com/lvm-resize-how-to-decrease-an-lvm-partition/
https://wiki.archlinux.org/index.php/Resizing_LVM-on-LUKS
https://blog.shadypixel.com/how-to-shrink-an-lvm-volume-safely/
https://unix.stackexchange.com/questions/41091/how-can-i-shrink-a-luks-partition-what-does-cryptsetup-resize-do
LVM-fragmentation
See the discussion in the following link:
https://askubuntu.com/questions/196125/how-can-i-resize-an-lvm-partition-i-e-physical-volume
https://www.linuxquestions.org/questions/linux-software-2/how-do-i-lvm2-defrag-or-move-based-on-logical-volumes-689335/
Introduction into LVM
https://www.tecmint.com/create-lvm-storage-in-linux/
https://www.tecmint.com/extend-and-reduce-lvms-in-linux/

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

Posted on by

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://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
...

r

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/

 

DSGVO, Freelancer, E-Mails und ein Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – I

Posted on by

Als Freelancer hat man seine liebe Not mit der deutschen Last-Minute-DSGVO-Panik. Das Problem ist nicht der Datenschutz an sich; da sind die allgemeinen Anstrengungen eher lobenswert. Das Problem sind vielmehr pauschale Verträge oder Vereinbarungen zur Auftragsverarbeitung, die viele Datenschutzbeauftragte (in ihrer Hilflosigkeit?) uns Freelancern aufdrängen möchten. Dabei spiegeln solche pauschalen Verträge nach meiner Auffassung gerade nicht den Geist der DSGVO wider:

Verkannt wird dabei, dass Datenschutz und Datensicherheit gemeinsame Festlegungen erfordert (s. etwa Art.32 DSGVO). Der Auftraggeber muss nämlich die technischen und organisatorischen Maßnahmen kennen und damit in gewisser Weise auch gutheißen, die Bestandteil eines Vertrages werden sollen. Viele Datenschützer übersehen auch, dass die zu erwartenden personenbezogenen Daten und deren Schutzniveau erstmal definiert werden müssen. Entsprechend inhaltsleer fällt denn auch die Antwort auf die Rückfrage aus, welche personenbezogenen Daten denn in der Zusammenarbeit auftauchen werden.

Man ist als Freelancer also gut beraten, die Schutzbedingungen selbst mit zu definieren – gerade im Geiste der DSGVO, Art. 32, Pkt.1. Das gilt dann u.a. auch für den Austausch von Mails zwischen Auftraggeber und Auftragnehmer.

E-Mail-Verkehr als DSGVO-Problemzone

Das Thema E-Mail ist im Kontext des Datenschutzes für Freelancer durchaus ein kritisches. E-Mails sind von Haus aus mit personenbezogenen Daten behaftet und können weitere schützenswerte Inhalte beinhalten. Hier muss man das zu erreichende Schutzniveau von beiden Seiten also sorgfältig definieren. Dabei muss man einen zwischengeschalteten Provider berücksichtigen – aber natürlich auch die hauseigene E-Mail-Installation. Letztere wird bei Linux-Lovern und -Profis durchaus komplex ausfallen, da der Linux-Anwender/Admin aus vielen vernünftigen Gründen heraus ggf. einen eigenen Mail-Server mit oder ohne Zusammenspiel mit einem Mail-Server bei einem Providern betreiben wird.

Ende-zu-Ende-Verschlüsselung?
Sinnvolle Schutzwege führen bei E-Mail aus meiner Sicht eigentlich immer über Ende-zu-Ende-Verschlüsselung. Kann man die DSGVO also als eine Gelegenheit begreifen, Verschlüsselungspflichten endlich auch für den Auftraggeber zu fixieren? Am besten auf der Basis von OpenPGP? Ich bezweifle aus Jahren eigener schlechter Erfahrung leider, dass alle eure Auftraggeber zu diesem Schritt der Vernunft bereit sein dürften.
Alternative? DE-Mail mit OpenPGP? Ehrlich gesagt: Ich weiß nicht, warum das technisch einfacher sein soll, als gleich selber die Schlüsselverwaltung zu übernehmen – und dabei ganz ohne Browser- oder Client-Plugins auszukommen. DE-Mail ist zudem kostenpflichtig – und man handelt sich ein paar unangenehme Verbindlichkeiten bzgl. der Nutzung ein.
Dennoch ist Mail-Verschlüsselung (ob mit oder ohne DE-Mail) der zu wählende Königsweg.

Nur Verschlüsselung des Übertragungsweges?
Leider fühlen sich viele AGer mit OpenPGP überfordert. Was dann? Nun, meistens haben die Auftraggeber selber E-Mail-Provider – und zumindest erfolgt der Zugang zu den E-Mail-Servern selbiger Provider verschlüsselt. Dito natürlich beim Freelancer. An dieser Stelle erscheint es geboten, als Freelancer einen Auftragsverarbeitungs-Vertrag mit dem Provider abzuschließen, den die meisten Hosting-Provider in Deutschland in pauschaler, aber ggf. hinreichender Weise anbieten.

Schutz unverschlüsselter Mails?
Leider ist man mit der Verschlüsselung des Übertragungsweges als Freelancer nicht aus dem Schneider.

Das erste Thema sind E-Mail-Clients (PCs, Notebooks, ..), die E-Mails in einer unverschlüsselten Umgebung puffern, öffnen oder gar mit Servern synchronisieren (unter Linux etwa über KDE’s Akonadi oder z.B. über Evolutions und Thunderbirds eigene Tools). Auf den Clients bleibt
dann halt viel auf deren meist unverschlüsselten Platten liegen.

Das zweite Thema, das vermutlich gerade Linux-Lover trifft, sind eigene E-Mail-Server im (Home-) Office-LAN. Jeder Freelancer oder auch der Admin eines KMU, der bei seiner Infrastruktur auf Linux setzt, wird aus einer Vielzahl von Gründen früher oder später einen eigenen Mail-Server aufgesetzt und den ggf. an einen Mail-Server bei einem Provider angeschlossen haben. Das gilt im Besonderen dann, wenn noch weitere Mitarbeiter oder Unterauftragnehmer im Spiel sind: Unter Upgrade-, Migrations- und Backup-Gesichtspunkten stellen eigene Mail-Server (trotz der Mühen beim Setup) für den Freelancer letztlich eine Arbeitserleichterung dar. Auf einem solchen Server lagert nun womöglich eine Masse an unverschlüsselten Mails auf unverschlüsselten Festplattenpartitionen. Steht etwa im eigenen (Home-)Office-LAN ein eigener Linux-Mail-Server, stellt sich die Frage wo und wie man die dort auflaufenden E-Mails bei Abwesenheiten/Urlaub von der Wohnung oder seines Office schützt.

Physikalischer Zugangsschutz? Nun, Freelancer werden kaum die Möglichkeit haben, ihre Wohnungen voll zu verriegeln, ohne sich Ärger mit Vermietern einzuhandeln. Wie sichert man sich dann gegen Diebstahl zu schützender Mails im Falle eines Einbruchs während eines Urlaubs ab? Tja – genau mit diesem Problem muss man sich nun ggf. wegen relativ strikter (pauschaler) Auftragsverarbeitungsvereinbarungen mal wieder auseinandersetzen. Das halte ich persönlich für durchaus sinnvoll …

Gefordert ist natürlich erneut Verschlüsselung – diesmal aber von Platten oder Partitionen.

Verschlüsselung von Platten und Partitionen – auf Mail-Servern wie Mail-Clients?

Während Notebooks sowieso durchgehend kryptierte HHDs/SSDs erfordern, ist eine Vollverschlüsselung von Festplatten/ Partitionen bei Servern und umfänglichen Workstations ein viel komplexeres und problematischeres Thema, das auch mit Risiken verbunden ist. Ich nenne nur mal beschädigte Krypto-Header als eines der potentiellen Probleme.

Nehmen wir mal an, man traut sich zu, die Risiken, die mit Kryptographie verbunden sind, zu beherrschen. Wie kann dann für den Linux-Lover ein praktikables Modell für den Schutz unverschlüsselter Mails aussehen? Ich meine, dass drei strategische Elemente zum Ziel führen:

  1. Abseparation von bestimmten E-Mail-Accounts für Kunden
  2. Virtualisierung der E-Mail-Server – wie einer E-Mail-Client-Umgebung unter KVM/QEMU
  3. Verschlüsselung der (Raw-) Partitionen/Volumes, auf denen E-Mail-Server oder aber die Client-Umgebung operieren.

Auf mobilen Laptops/Notebooks ist eine Kryptierung der benutzten Partitionen sowieso Pflicht. Für SSDs ist dabei zu beachten, dass die Verschlüsselung schon im jungfräulichen Zustand erfolgen muss.

Nun wollen wir die Verschlüsselung aber auch auf Workstation-Clients und Server anwenden. Der E-Mail-Datenverkehr läuft dann meiner Ansicht etwa wie folgt aus:

Ein Router mit Perimeter-Firewall übernimmt die Kommunikation mit dem Internet. Er trennt ggf. ein Gastnetz [GNS} von einem Frontend-Segment [FNS]ab. Ein System mit einer Paket-Filter-Firewall und/oder WAF-Firewall trennt weitere nachgelagerte Segmente ab. Ein zweites System GWS2 realisiert einen E-Mail-Server in einer Art sekundärer DMZ. Dieser Server wird entweder direkt von normalen Clients in weiteren Zonen angesprochen (Lösung für “Arme”) oder synchronisiert Mails ggf. mit einem weiteren Groupware-Server in internen Segmenten (Lösung für “Reiche”).

Kennt man sich gut mit Paketfiltern im Kontext virtualisierter
Netze gut aus, kann das angedeutete System “GWS1” ggf. entfallen. Auch der Groupware-Server ist für einen reinen Mail-Betrieb nicht erforderlich.

Die Verschlüsselung der Volumes, die von den unter KVM/QEMU virtualisierten Servern/Clients genutzt werden, kann dabei auf dem Host bereits auf der Ebene einer Linux-“Raw”-Partition oder eines “Raw”-LVM-Volumes genutzt werden. Ich halte in einem solchen Szenario allein aus Performance-Gründen Einiges davon, die Verschlüsselung dem Virtualisierungshost zu überlassen. Sollte jemand dagegen gute Einwände haben, bitte ich um Kontakt per E-Mail ….

Zusammenfassung und Ausblick auf den folgenden Artikel

Der regelmäßige Austausch von E-Mails, die personenbezogene und andere vertrauliche Daten beinhalten, erfordert mit Auftraggebern ggf. einen Vertrag, der die Art und Qualität personenbezogener Daten definiert, zu erreichende Schutzniveaus festlegt und technische wie organisatorische Maßnahme zu deren Umsetzung regelt.

Eine wichtige Maßnahme bei Freelancern, die keinen hinreichenden Zugangsschutz zu eigenen Systemen garantieren können, erscheint mir dabei die Lagerung der E-Mails auf verschlüsselten Partitionen und Volumes zu sein. Will man nicht gleich alles verschlüsseln können virtualisierte Systeme zum Zuge kommen.

In kommenden Artikel

DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – II

gehe ich zunächst noch einmal auf ein paar Aspekte der DSGVO ein und begründe etwas genauer, warum ein vertragliches Abkommen mit einem Auftraggeber sinnvoll ist. In einem dritten Artikel widme mich dann mal dem Umzug eines Linux-E-Mail-Servers – und dabei speziell dem Umzug einer bereits existierenden virtualisierten Lösung – auf neue, verschlüsselte Partitionen oder LVM-Volumes des Hosts. Entsprechende Arbeiten für Client-Systeme sind dann recht ähnlich.