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

[Mike Kazantsev]

On Wed, 11 Jul 2012 09:29:55 +0200
David Härdeman <david at hardeman.nu> wrote:

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

With systemd password agent, I think it can be solved in the following
way:

1) /run/systemd/ask-password/ask.foo is created and
systemd-ask-password-console pops up a prompt for it.

2) At the same time, systemd-smartcard-password agent detects the
created file and reads it, then check for a smartcard device, waiting
for it to appear.

3) If/when proper smartcard device appears (and is recognized by
middleware), it unlinks /run/systemd/ask-password/ask.foo and prompts
for PIN.

4) systemd-ask-password-console detects query-file removal and hides
it's prompt, leaving only query for PIN.

5) If PIN provided to systemd-smartcard-password is incorrect (or
smartcard disappears, or user times out), it provides systemd with
empty password (emulating it being incorrect) or "request cancelled"
response.

Does it make any sense?


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

While probably exactly not what you seek, but I've actually implemented
smartcard / systemd / cryptsetup glue about a year ago.

It doesn't work purely on systemd-level though, as dracut had to get
the key first, and I didn't have systemd in it at that moment.

To get the key for LUKS slot, udev rule is generated by dracut (if
proper cmdline flag was present), which runs a script once smartcard
is detected, which extracts the key (as necessary) and just puts it
into /run/initramfs (with strict root-only permissions).

After that, both dracut (with a bit patched "crypt" module) and custom
systemd password agent try to satisfy password requests (for
popping-up encrypted lvm partitions) from that cache-file.

Specal .service removes that file After=local-fs.target.

Not sure if this description is useful to you, but that's one (still
working flawlessly, btw, though maybe by accident) way to support that
feature.

Agent implementation can be found here:
  https://github.com/mk-fg/systemd-password-agent/blob/master/systemd_password_cache.py

A post describing the process in (maybe) a bit more detail:
  http://blog.fraggod.net/2011/10/dm-crypt-password-caching-between-dracut-and-systemd-systemd-password-agent


> Regards,
> David


-- 
Mike Kazantsev // fraggod.net