[pkg-cryptsetup-devel] Scripting hooks for entering a password

[Shawn Rose]

Hi, this might seem like an odd request but I'm currently trying to port
clevis (https://github.com/latchset/clevis) to initramfs, and right now I
have run into a bit of a problem.

In short, there isn't really a 'good' way to wait for the password request
from the cryptroot script and act upon it: right now, I have been using a
subshell with a loop and sleep calls to check to see if the
ask-for-password/askpass processes are running, and if they are to scrape
and find which disk they are attempting to unlock, before piping the
correct password to /lib/cryptsetup/passfifo.

It WORKS, but it's somewhat kludgy, and #debian-kernel recommended (more
than once!) to talk to the cryptsetup team to discuss what you thought I
should do.

One problem with the way it works now (Of course discarding the whole
subshell business and how I have to grep ps and then /proc/pid/cmdline to
get the disk path) is that if clevis fails to get the password and the user
enters a password manually, then after a while the script will close out
the subshell saying that sleep can't be found. I did set it up so that I
use set -e in the subshell (clevis itself already uses bash, so there isn't
really a problem with importing that to initramfs) so it doesn't SPAM it,
but I'd still rather avoid it.

I'll be honest, even with edits I can't really see any way to avoid a
subshell, but I am somewhat new to this kind of thing and it would be nice
to have the clevis project properly packaged for debian and derivatives, so
I want to make a good faith in getting it working in a proper fashion.

Here's the script that I have thus far if you want to see how it works.

https://github.com/ShaRose/clevis/blob/master/src/initramfs/clevis-script

Just as a short description, clevis-luks works by storing an encrypted JWE
containing a password which is added to the luks container, and then
storing this in luks metadata using the luksmeta project (
https://github.com/latchset/luksmeta). When clevis runs, it uses luksmeta
to get the JWE and then attempts to decrypt it. The decryption can require
a few different pins: the contents of an http page, or use a tang server (
https://github.com/latchset/tang), or even use shamir's secret sharing so
that N pins are required to decrypt the password. Long story short: If the
server boots and can access the right servers, then it can unlock itself
automatically, sort of like how bitlocker can do a network unlock.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20170621/8924a616/attachment.html>