New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cryptsetup: add support for the keyscript= option #3007

Open
wants to merge 1 commit into
base: master
from

Conversation

@tchernobog

tchernobog commented Apr 10, 2016

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.

cryptsetup: add support for the keyscript= option
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

This comment has been minimized.

Contributor

falconindy commented Apr 10, 2016

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

This comment has been minimized.

tchernobog commented Apr 10, 2016

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

This comment has been minimized.

Member

poettering commented Apr 25, 2016

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

This comment has been minimized.

tchernobog commented May 2, 2016

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

This comment has been minimized.

johanna-a commented May 6, 2016

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

This comment has been minimized.

tukss commented Jun 30, 2016

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

Elbandi suggested changes Jun 18, 2017 edited

and need to change one line more:

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

and move parse_options call before that

r = WEXITSTATUS(status);
if (r == EXIT_SUCCESS)
{
char line[LINE_MAX];

This comment has been minimized.

@Elbandi

Elbandi Jun 18, 2017

char line[LINE_MAX] = { 0 };
@wildy

This comment has been minimized.

wildy commented Sep 6, 2017

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

This comment has been minimized.

bam80 commented Sep 6, 2017

Any chances to merge soon?

@iam-TJ

This comment has been minimized.

iam-TJ commented Sep 17, 2017

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.

@Zythyr

This comment has been minimized.

Zythyr commented Jan 28, 2018

I am trying to use keyscript in crypttab to unlock an encrypted partition. Haven't no success. It seems this bug is the one causing the issue.

Any idea when this issue will be fixed?

@Fmajor

This comment has been minimized.

Fmajor commented Jul 28, 2018

Is there any progress? I really miss the keyscript= option.、
=======update===========
i found a workaround here

# vim /etc/default/grub
## add 
cryptopts=target=sda4_crypt,source=/dev/disk/by-uuid/a0a9abbb-8321-3213-a7c8-0f04aa2f11b9,keyscript=/lib/cryptsetup/scripts/get_key
## to GRUB_CMDLINE_LINUX_DEFAULT=
## change the 'sda4_crypt' and uuid with the name in your /etc/crypttab
# update-grub

now keyscript is coming back

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment