decrypt multiple devices on boot

[hede5562]

I have adapted mortar to be able to decrypt two devices for a dm-raid/btrfs configuration.

This is just a proof of concept. I'm running Debian on some older PC with TPM 1.2 only. So I extended mortar only for debian and TPM 1.2 and it works so far.

For this reason this is a draft pull request for discussion and not for direct inclusion!

I'm using btrfs on two luks devices but using some dm-raid/lvm configuration would be the same.

The main visible change in mortar.env is: removing CRYPTDEV and CRYPTNAME variables in favor of a CRYPTNAMES variable. CRYPTNAMES is a list of crypt device names from crypttab. See mortar.env and code changes for further information. This eases configuration a little and makes UUID=xxx devices possible.

[noahbliss]

Hey! Cool work you're doing here. Couple of comments though, can we please have functionality that allows us to specify the path to the device then the cryptname? This can be useful if we are trying to use mortar on a system that currently doesn't have a crypttab or for users who want to change this mapping up. Generally I prefer the "declarative" approach as default, with "smart" as a fallback. Perhaps something like:

CRYPTNAMES="/dev/disk1path:disk1name /dev/disk2path:disk2name"

as the default/preferred, but keeping your functionality that goes and finds the path if it can in event the user did not set the path manually. E.g.

CRYPTNAMES="/dev/disk1path:disk1 disk2name"

If we could also split your cleanup of my code (thanks btw) into a separate PR, that would be great. Not sure where all that was done, but I did see the switch of sourcing mortar.env in the 1- script.

[noahbliss]

As a side note to readers, it appears this approach has the tradeoff of using the same key in the TPM to unlock both/all drives. If this is acceptable for your use case, this can be a pretty useful feature and one I would be fine adding along with this caveat in the readme, but just a heads-up.

[hede5562]

The style CRYPTNAMES="/dev/disk1path:disk1name /dev/disk2path:disk2name" was indeed my first idea. I am also a big fan of "if the computer tries to be smart this typically fails much to often". But in the end I didn't see a reason to do so as I thought if you have an encrypted system disk you have to have en entry in the crypttab. For example if you are just creating an encrypted system disk then (which is the case if you want to decrypt it before starting the OS) then creating a crypttab at least doesn't harm (for any case it does there's the "noauto" option).
In the end there's one place where the mapping is defined and not several different configuration files.

For the PR splitup: I tried to split different functionality to different commits. For cherry picking single commits. There are some collisions as some of the commits do not work by themselfs alone, but for the named 1--file fix that's (AFAIR) a commit by its own.

And yes, you are absolutely correct with your side note. The idea was to have a single key for single data as the intend is to decrypt multiple raid drives (on the one hand) and for multiple independent drives (on the other hand) if one of the keys is compromised this is obviously the drive with the most sensitive data or the root drive (Murphys law, you know...) and this one will give the attacker full access to your data anyway. ;-)
Just kidding, maybe some option to specify multiple keystores is some useful future task, but this - in my opinion - has a low priority.

[FabianSchurig]

Hello @hede5562 ,

Maybe you want to checkout and review my approach on using multiple disks with different passwords for encryption in #42

#42 could be easily applied for TPM1.2 as well.

Thank you very much!
Best Fabian