Hi Laurent,
On Tue, 10 Jan 2017 at 01:07:00 +0100, Laurent Bigonville wrote:
> Looking at systemd, I see that they are doing something similar:
>
> serial = add_key("user", keyname, p, n, KEY_SPEC_USER_KEYRING);
>
> with keyname="cryptsetup"I just had a look at this and as I wrote in #917067's message 65: | AFAICT, when systemd tries to open a LUKS device, it starts by searching | in the user keyring for a key named “cryptsetup”. If found, the content | is interpreted as a NUL-delimited list of passphrases, each one being | successfully tried against the device to open. At this point, if the | device is still locked, the user is prompted for the passphrase until | the device opens, or until the maximum number of tries exceeds; moreover | each passphrase entered (whether it's valid or not) is appended to the | NUL-delimited list contained in the key named “cryptsetup”. | | However I'm personally extremely reluctant to adopt such logic in | src:cryptsetup (for instance in cryptdisks_start(8) or in our initramfs | scripts), because 1/ splitting on NUL bytes breaks binary passphrases, | which are currently allowed through askpass' passfifo; and 2/ | successively trying each passphrase previously entered is a waste of time | and resources, especially with modern PBKDFs. Does this pam module splits on NUL bytes as well, or take the raw content of the user keyring? > I see two options here, either debian/askpass.c is modified to either call > add_key() function directly or "--keyname=cryptsetup" is passed to > systemd-ask-password. I assume you want the passphrase used for unlocking at initramfs stage to be used later? Then `systemd-ask-password --keyname=cryptsetup` isn't an option, because systemd-ask-password(1) is not copied to the initramfs image. IMHO caching passphrases passed to askpass should not be the default. Since Linux 4.10 it's possible to offload volume keys of dm-crypt targets to the kernel keyring. This is the default for LUKS2 devices (due to be the default LUKS format some time early next year), and such volumes keys can't be read by userspace. Hence caching passphrases, even with a timeout, does change the threat model somewhat. Moreover, the order in which dm-crypt devices are mapped at initramfs stage is currently undocumented. Not a big deal, we could certainly document that, but what if there are several targets? Should we try to use the last cached value before prompting the user? I'm really not keen on caching all passphrases (valid or not) in a NUL-separated list like systemd does. If there are several passphrases for the targets, should we keep only the first one, or should the later one override it? > Or the keyctl command line is used with something like: keyctl add user > cryptsetup my_password @u Our ‘decrypt_keyctl’ keyscript can be used for that. Currently the key name is hardcoded to "cryptkey-$CRYPTTAB_KEY" (where $CRYPTTAB_KEY is the value of the 3rd column), but it's an implementation detail and we could change that to "cryptsetup" when $CRYPTTAB_KEY has a special value like "none". (Conveniently "none" has a special meaning when there is no keyscript, and used to to have vague semantics with keyscripts, cf. #826124.) We could also add a crypttab(5) flag like “cache” and implement the caching logic in askpass (checking whether the CRYPTTAB_OPTION_cache environment variable is set), but I don't see the advantage over decrypt_keyctl. Moreover, introducing new crypttab(5) options is sub-optimal since it increases our delta with the systemd implementation. Cheers, -- Guilhem.
signature.asc
Description: PGP signature
