Resizable encrypted LVM requiring just one password on boot (encrypted volume group)?
 

Hello!

I wonder if following configuration for full disk encryption is possible
with some of the current distros:

Level 1:
2 physical disks (/dev/sda, /dev/sdb)

Level 2:
RAID1 /dev/md0 over /dev/sda1 and /dev/sdb1 as /boot
RAID1 /dev/md1 over /dev/sda2 and /dev/sdb2

Level 3:
Encrypted LVM volume group /dev/vg00 over "unencrypted" LVM physical disk /dev/md1

Level 4:
LVM logical volume /dev/vg00/lv00 as swap over encrypted volume group /dev/vg00
LVM logical volume /dev/vg00/lv01 as / over encrypted volume group /dev/vg00
LVM logical volume /dev/vg00/lv02 as /home over encrypted volume group /dev/vg00
...

I have found other common configuration on the web: LVM over encrypted /dev/mdX partitions - but this requires entering password for each encrypted /dev/mdX partition upon boot. While in my configuration above this would be just one, if I later decide to extend LVM volume group by adding another physical volume /dev/mdX (on additional physical disks), I would have to enter one more password upon boot, even if they would be the same.

I'm wondering could this work if you first generate a key
and then initialize the assembled md devices with the same key?

I am not sure if it is supported by distro init scripts. I´d guess init scripts do not try password entered for previous encrypted volume on the next encrypted one.... If they would, I could use the more common configuration LVM on encrypted /dev/mdX.

/etc/crypttab?:
Else why not combine /dev/sd{ab}{1,2} into one md, LUKS the whole md and divide that into VGs?

I mean: Ideal startup script would work like this:

1) Found encrypted partition?
2) If yes, do I have the right encryption/decryption key set? If yes, mount/read the partition.
3) If not, do I have the right encryption/decryption key password set? If yes, read and decrypt key with the password, set a variable with the key value and then goto 2)
4) If not, read the password from user (terminal), set a variable with the password value and then goto 3)

But I doubt ANY startup script is that smart. Script writers don´t have any imagination. In my whole life, I might see max. 5 script written according to defensive programming rules.
The rest of scripts just hopes everything will be right a then screw it with the rest of the code :-)

Its OSS so BMG and do something (instead of talking) about it...

Moved: This thread is more suitable in the Software forum (not a security issue) and has been moved accordingly to help your thread/question get the exposure it deserves.

Point taken.

I think there would be issues with crypttab solution in case of hibernation. I guess this would not work with just one password input.

But maybe I could create nested RAID:

Layer:
1. /dev/md1 over /dev/sda2, /dev/sdb2 - RAID1 on lowest level
2. encrypted /dev/md2 over /dev/md1 - JBOD over RAID1 (initially with just one member)
3. LVM over /dev/md2

If I later decide to extend /dev/md2 with another physical disk, I can create /dev/md3 over /dev/sdc1 and /dev/sdd2 and then grow /dev/md2 by adding /dev/md3 to it(?).
I am just not sure if mdadm supports this.... (?)

Yeah, what doesn't cause problems combined with hibernation? ;-p


It's something you could test?