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

[Lennart Poettering]

On Tue, 10.07.12 10:35, David Härdeman (david at hardeman.nu) wrote:

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

Well, but for that we already have the agent logic...

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

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

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.

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

> 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?

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.

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

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

Lennart

-- 
Lennart Poettering - Red Hat, Inc.