cryptsetup: add support for the keyscript= option

[tchernobog]

One of the last and most important missing options to fully support
the old crypttab, is support for "keyscript=". This is especially
important for people with custom setups, such as those retrieving the
key from a smartcard.

This patch adds such option, and updates the documentation accordingly.
It also offers a compatibility layer with Debian by setting some useful
environment variables, and rendering them available to the keyscript
when run.

[falconindy]

Ignoring the numerous missing error checks and style violations, support for this has been discussed before and ultimately shot down:

https://lists.freedesktop.org/archives/systemd-devel/2012-July/005835.html

[tchernobog]

Ignoring the numerous missing error checks and style violations,

That I would be willing to fix, certainly. This is my first attempt, sorry if I got style or checks wrong. I am open to suggestions; I already noticed problems with the indentation, for instance, now that I see it as a patch. Sorry about that.

support for this has been discussed before and ultimately shot down:
https://lists.freedesktop.org/archives/systemd-devel/2012-July/005835.html

Thanks for pointing out the thread. One of the issues however, is that scripts allow the user to really adapt them to their own situation. I.e. I have an OpenGPG-compatible card with some extra data which I want to be used as a key. It is fairly easy to write a script for it, but if you have 10 different users, you probably end up with 10 different scenarios. I don't know if attempting to handle them all would render the logic of cryptsetup too complex.

By looking at the thread, it looks more like the discussion dwindled down. Would then the outline sketched by Mike Kazantsev (https://lists.freedesktop.org/archives/systemd-devel/2012-July/006057.html) be satisfactory to start writing a patch for systemd?

[poettering]

I am still not convinced that keyscript= is such a good idea. There's ask-password already in place which is kind of a proper API for this already.

I think if Debian wants keyscript=, they should add this downstream.

Smartcard stuff sounds like something to support directly in cryptsetup I figure, if that can be reasonably done, see #2776 for example.

What other usecases are there for keyscript=, that neither proper smartcard support nor ask-password can cover?

(BTW, I consider the smartcard stuff a really bad usecase for keyscript=, since it's hw bound, and that means a single script invoked at the time the pw is needed tends to be wrong, since it cannot deal with the fact that hw is hotplugged dynamically and might appear at any time.)

[tchernobog]

Thanks @poettering for the commentary. You're probably right, it might make sense to define a common infrastructure for acquiring smartcard authorization keys. It might entail making some assumptions though (what to do when there are more smartcard readers connected, more keys on the smartcard - and how to use the (signing|auth) key to decrypt the storage, etc.).

I would say then not to merge this back in systemd - maybe Debian would like to grab it to support old behaviour, until an alternative is in place. But downstream as a temporary fix would be also okay.

Could you please outline in very rough steps what would be an acceptable solution to add another password provider for smartcards? It probably needs to be configurable. Thanks!

[johanna-a]

Having read up on this, I would suggest the following outline for pkcs11 support:
crypttab specifies a pkcs11 URI (https://tools.ietf.org/html/rfc7512)
cryptsetup-generator.c makes sure that a pkcs11 provider is required if a pkcs11 URI is specified
(systemd) cryptsetup.c passes the pkcs11 URI to the "real" cryptsetup in a similar way to how keyfiles are handled.
pkcs11 support is implemented in cryptsetup + cryptsetuplib (probably in something like lib/utils_pkcs11.c)

Everyone is happy until someone requires cryptsetup to timeout. Which they shouldn't.

Unsolved:
cryptsetup may need to ask for a PIN to unlock a slot on a pkcs11 token. In this case (systemd) cryptsetup-generator must recognize this from the pkcs11 URI and use the normal passphrase logic to ask for a PIN to supply to cryptsetuplib. But it will (probably) get messy.

[tukss]

One Debian keyscript that is not covered by systemd-ask-password nor related to smartcards is /lib/cryptsetup/scripts/decrypt_derived. It is used to extract a derived passphrase from an already opened LUKS device, which is useful to open multiple encrypted devices by entering a single password. A possible use case is multiple LVM PVs, each of which are on encrypted devices. I am not saying the keyscript option is the only way to go here. Probably something simpler would be better. Or am I missing that this is already possible with the current handling of crypttab in systemd?

[Elbandi]

and need to change one line more:

if (!path_is_absolute(argv[4]) && !arg_key_script)

and move parse_options call before that

[Elbandi]

char line[LINE_MAX] = { 0 };

[wildy]

Another case that (I presume) is not covered by password agents is, when you require some external program to pull the key over a (secured) network connection so that volumes to be decrypted require actually being on a certian network.
That, or can it be done with password agents?

[bam80]

Any chances to merge soon?

[iam-TJ]

This has broken many FDE PCs I manage and provide support for, where they use a variety of (usually USB device [ yubikey, mass-storage, inverse path Armory, etc.], network supplied) methods of obtaining the key material.

As a practical matter, when you replace an existing tool at least implement all it's core functionality to avoid these kinds of severe regressions.

The keyscript= functionality puts control of how and where the system obtains the key material in the hands of the system administrators where it belongs, rather than subject to developers who seem to have no real interest in this important functionality (this has been going on since 2012!).

So how about implementing keyscript= support so admins can get on with maintaining FDE devices for another 5 years whilst the 'correct' solution is developed and delivered?

Alternatively, why not provide a simple way to disable the systemd-cryptsetup generators and fall-back to the original cryptsetup handling if the admin so chooses?

Either way, we get back the original functionality that has been lost for so long.