[pkg-cryptsetup-devel] Bug#850756: Bug#850756: cryptsetup: Please save password to kernel keyring

[Guilhem Moulin]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20181225/517643bb/attachment.sig>