On Tue, 10 Jul 2012 16:25:50 +0200, Lennart Poettering <lenn...@poettering.net> wrote: > On Tue, 10.07.12 10:35, David Härdeman (da...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
