[systemd-devel] [PATCH] add keyscript support to cryptsetup

[David Härdeman]

On Tue, 10 Jul 2012 16:25:50 +0200, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 10.07.12 10:35, David Härdeman (david at hardeman.nu) wrote:
>> Whenever a user comes up with another scheme for storing keys (you've
>> already seen some...like storing keys between the MBR and first
>> partition using the keyfile-offset= parameter), it is possible to ask
>> them to use a keyscript= instead of extending the cryptsetup logic.
> 
> Well, but if this is all dependent on some other hw then the synchronous
> nature of keyscript= doesn't work anyway... (see other mail about that)

I think you're making a much bigger issue out of the "synchronous nature"
than warranted.

In the current systemd solution, the systemd-native cryptsetup binary will
request a password using a /run/systemd/ask-password/ask.foobar file, then
wait until it gets one or more answers back via a socket. If some password
agent used e.g. a USB smartcard reader, it would naturally wait (exactly
how it waits is not that important) until said reader is available before
it could theoretically provide said answer. If the partition is necessary
for booting the system, the boot will wait until the key is provided and
the partition is mounted.

In the Debian cryptsetup init scripts, the keyscript will be executed and
the cryptsetup binary will wait until it gets an answer back.

Having keyscripts check and wait for certain /dev files to be present is
not much of an issue and it makes very little difference in the
"asynchronous" nature of the solution. The scsi_wait module and/or commands
like udevadm settle, etc, are not strictly necessary in a keyscript.

So, neither solution is, as far as I can tell, more "asynchronous".

> Both yubikeys and most smartcard readers are USB devices, so you always
> have the enumeration issues, which means a synchronous solution wouldn't
> work wihtout races anyway and the async agent stuff is much preferable.

See above.

>> >http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents
>> 
>> I also dislike additional complexity and realize that systemd is an
>> excellent oppurtinity of providing some much needed spring cleaning in
>> distribution-specific boot scripts - but there are a few problems with
>> using password agents:
> 
> Well, the complexity comes for a reason: correctness.

I think you misunderstood me. I wasn't referring to systemd password
agents when I said "complexity", I was referring to the legacy features
such as "keyscript=".

>> 1) Backwards compatibility
>> 
>> "keyscript" has been supported by the Debian cryptsetup package for a
>> long time and people already have keyscripts. Some of these are used
for
>> boot-critical partitions. Just telling everyone to rewrite whatever
they
>> have as passwordagents is unlikely to be accepted.
> 
> We do take the liberty to break compatibility  in some cases, where we
> believe the previous choice was broken or where we have really good
> reasons to. We do document them though (for example
> http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities) so
> maybe that's one of those things where we should break the compat and
> document it?

That's fine by me. I understand that systemd has some ambitious goals wrt.
cruft removal and distribution consolidation, both of which I applaud. As
long a some other scheme is in place which allows similar functionality.

> Note that if compat is really that important it should be possible to
> write an agent that can invoke keyscripts like this. If you did that you
> would gain, among other things the ability to query for passwords at the
> same time via different methods. With a bit of C code it should be
> fairly easy to hack up an agent that just invokes a keyscript.

The biggest question in my mind right now is how the "keyscript" password
agent should be implemented and how it should interact with the other
agents.

Imagine the scenario where crypsetup wants to set up a partition using a
binary key from a smartcard, which in turn requires a PIN to be entered:

1) Following the current logic, the systemd cryptsetup binary would ask
for the key to the partition using /run/systemd/ask-password/ask.foo. (That
file could potentially be extended to add something like an "Options="
field where we could provide additional information about the password
request to the agents).

2a) The "keyscript" agent would read the ask.foo file and determine that
it can provide the requested key from a smartcard (I assume this knowledge
comes from some config file)

2b) At the same time, the other agents provide normal password input
prompt(s) to the user (e.g. on the tty)...which are pointless since a
binary key is expected.

3) Soon afterwards, the "keyscript" agent in turn uses
/run/systemd/ask-password/ask.bar to request the PIN for the smartcard.

4) The user would be confronted with two passphrase prompts. One
(pointless) one to provide a binary key using the keyboard, and one (real)
prompt for the PIN to the smartcard.

I'm not sure what kind of changes to the password agent scheme you're
envisioning to accommodate a scheme like this?

>> 2) PasswordAgents can't handle binary strings
>> 
>> keyscripts typically generate the key for the device and pass it to
>> stdout. PasswordAgents can't handle binary strings which contain NUL
>> characters (for example).
> 
> Well, the proto would actually allow binary passphrases. We could
> relatively easily fix this if people really have a need for this.

I've already provided an example where there is a need: smartcards - they
usually provide the key blob (after the correct PIN has been entered) and
not some passphrase which needs to be further hashed, etc. The same goes
for any keyscript solution which fetches a key (from somewhere, anywhere)
rather than a passphrase.

But yes, the password agent protocol could be extended to support binary
passphrases (right now, a leading '+' or '-' is expected, a binary
passphrase would just have to have a different leading character).

>> 3) systemd specific solution
>> 
>> Converting keyscript= scripts to password agents introduce a strong
>> dependency on systemd. I realize that you don't consider it to be a
>> problem but I'm guessing it wouldn't be acceptable to Debian (where
>> systemd is not mandatory).
> 
> Well, it's currently a Debian-init scripts specific solution...

Yep, but it's a useful solution. Right now you have no way of supporting
e.g. smartcards or other interesting sources of key material which might
come along down the line. Such functionality should be supported (not
necessarily by using keyscript= of course).

Regards,
David