Unlocking several crypto discs during boot

[Xen]

Volker Wysk schreef op 14-10-2017 20:28:
> Am Freitag, 13. Oktober 2017, 20:21:05 CEST schrieb Xen:
>> Volker Wysk schreef op 13-10-2017 19:46:
>> > -------------
>> > This could be done better by making the user enter just one password,
>> > and
>> > unlocking all matching crypto disks with it. So I would set the same
>> > password
>> > for both crypto disks, and would have to enter the password only once.
>> > This is
>> > my feature request.
>> > -----snip----
>> 
>> So how would you propose you would configure this?
> 
> This could be done automatically. No configuration needed.

That means the unlocker tool needs to scan all the headers and see if 
volumes have headers that are identically hashed. Possible yes.

Then what if someone DOESN'T want to unlock a secondary drive 
automatically?

> I don't understand. How could a LUKS container sit inside a LV?

Any logical volume can be turned into a LUKS container.

Just like every partition.

>> /dev/sda1 ---> PV ---> VG ---> root origin LV ---> LUKS ---> 
>> filesystem
>>                            ---> unencrypted LV
>>                            ---> unencrypted LV
>> 
>> /dev/sdb1 ---> PV ---> VG ---> root cache LV
>> 
>> This seems to be the preferred setup for encrypting and caching just 
>> the
>> root filesystem.
> 
> I have this situation: The /dev/sda3 partition is encrypted (using 
> LUKS). The
> encrypted partition (/dev/sda3_crypt) is made a PV, and the root LV is 
> inside
> that PV. The root filesystem resides inside that LV.
> 
> This would be better: The /dev/sda3 partition is a PV, and the root LV 
> is made
> inside it. Then the root LV gets encrypted. This way, a keyfile could 
> be used,
> and no second password was needed. (I believe, not quite sure).

Not even a keyfile.

If you put LUKS into your root LV, and then CACHE the root LV, obviously 
the CACHED DATA will ALSO be encrypted because on the outside it would 
ALSO be scrambled data.

So the cache device would only see scrambled data.

> The first possibility is what the Kununtu installer makes, when you 
> chose "Use
> the whole disk and configure encrypted LVM" (or similar). The manual
> configuration of the partitions was broken when I installed my 16.04.

The problem is that we have an issue with multiplexing.



1) encrypted LVM means that all LVs sit inside the decrypted partition, 
gaining 1 decryption for ALL logical volumes.

2) the alternative we now speak of does one-by-one encryption BUT there 
is no good infrastructure to decrypt multiple devices.

For instance: where are the desktop-based decryption tools?

Where can you decrypt prior to logging in?

It is very hard to open LUKS containers after boot.

Cinnamon and Unity probably do a reasonable job.

But you can't do it before logging in.


>> Your usecase is really not particular to caching. It is particular to
>> having multiple disks.
>> 
>> Or having multiple disks with LUKS containers.
> 
> I'ts particular to not being able to unlock LUKS containers via 
> keyfiles.

I guess that the cache device needs to be available prior to leaving the 
initramfs.

So you cannot use the root device to store the key... good one there, 
missed that.


>> So your feature request is really for decryption of multiple 
>> 'adjacent'
>> partitions that happen to have the same password.
> 
> Something like that.

Adding one last thing:

* You can use Grub to decrypt an encrypted boot device
* That means you can store a key in the initramfs
* You can modify an existing installation to do this.

* You just get an ugly Grub prompt for decryption.




- /etc/default/grub:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda1"
GRUB_ENABLE_CRYPTODISK=y

- /etc/crypttab:

sda1_crypt /dev/sda1 none         luks
sda3_crypt /dev/sda3 /keyfile.bin luks
sdb1_crypt /dev/sdb1 /keyfile.bin luks

(this assumes that boot is /dev/sda1, /dev/sda3 is LVM containing root, 
/dev/sdb1 is LVM containing cache volume.)

- /etc/initramfs-tools/hooks/copykey   (must be +x):

#!/bin/sh

cp /root/keyfile.bin ${DESTDIR}


* This is untested by me.
* The keyfile ends up in the root of the initramfs.
* Grub should try to open /dev/sda1
* the initramfs should try to open the other 2 devices.