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

[David Härdeman]

On Mon, Jul 09, 2012 at 10:49:56PM +0200, Lennart Poettering wrote:
>On Fri, 29.06.12 00:56, David Härdeman (david at hardeman.nu) wrote:
>
>> Debian's cryptsetup package supports the keyscript= option in /etc/crypttab
>> 
>> This patch is a first attempt at implementing support for the same option
>> in systemd. It is not at exact feature parity yet (environment variables
>> are missing and relative paths are not supported), but it's a start.
>> 
>> I'm not sure if the (somewhat complicated dance) with fds is considered
>> acceptable or if I should use something else?
>
>Humpf. So I am really not convinced that supporting this is really such
>a good idea. I am not a fan at all of this scriptlogic. (Starting with
>the fact that this is called keyscript=, i.e. as if this really needs to
>be a script...).

The name of the option (keyscript) doesn't mean that it needs to be e.g.
a bash script, it could be any executable.

>I wonder what the precise usecases for this are, and whether we can't
>find better solutions for these usecases... 

I originally implemented the keyscript= support in Debian, and the way I
see it there are two different usecases depending on your point of view.

As a package maintainer, or in this case systemd maintainer, the
keyscript= functionality was a good way of keeping bloat out of the
cryptsetup scripts (granted, some would probably say that the cryptsetup
scripts in Debian are already bloated, but without this functionality
they would be even more so).

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.

>From a user point of view it is of course additional flexibility which
is the usecase. I've seen keyscripts to use Yubikeys, keyscripts to get
keys off a smartcard (and the PIN for the smartcard could be requested
via systemd passwordagents or any other scheme), scripts which mount
different filesystems and grab the key off them, etc.

But yes, it might of course be possible to find a "better"
(non-backwards-compatible) solution. Starting with introducing support
for binary strings in PasswordAgents (see below).

>I mean, we already have the password agent logic, that is asynchronous,
>and way more powerful:
>
>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:

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.

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).

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).


-- 
David Härdeman