On Wed, 11 Jul 2012 09:29:55 +0200 David Härdeman <da...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
