Hi, On Sun, 25 Feb at 2018 12:01:02 +0100, Christoph Biedl wrote: > Now I'm somewhat stuck. If people with knowledge in initramfs and > especially the unlocking process there using cryptsetup could provide > some input, I'd be glad.
Given that cryptsetup's initramfs integration is not authored by
cryptsetup upstream but by the cryptsetup package maintainers, I really
wish we had been X-Debbugs-CC'ed in this RFH :-/
Nonetheless, thanks for your work that, on Jochen. I don't have time
for a full review right now, but with my cryptsetup & dropbear
maintainer — and coauthor of the initramfs scripts for both — hat on I
have a few comments at first glance. (I don't use GitHub so I'll
comment here instead.)
* /scripts/local-top/clevis: I guess I'm listed in the copyright
because some code was taken from cryptsetup-initramfs'
cryproot-unlock [0]. But that code uses undocumented bits, which we
consider internal implementation details, hence which MUST NOT be used
outside of src:cryptsetup. In particular, the path to the askpass
binary, and the fact running askpass processes have a CRYPTTAB_SOURCE
variable in their environment, are currently undocumented (and thus
are subject to change, possibly yielding an unbootable system).
Anyway, I don't think implementing the unlocking logic in an
initramfs boot script is the way to go. We have a documented
interface for using the output of a program as key or passphrase, and
clevis should use that instead of clevisloop(). That is, devices
that need to be unlocked at initramfs stage using clevis should have
a ‘keyscript=/path/to/clevis-wrapper’ in their crypttab(5) entry.
Further thoughts (in part moot because of the above):
* /hooks/clevis, /scripts/local-top/clevis: AFAICT these have no reason
to use /bin/bash in the shebang line. (FWIW I also think it's rather
unfortunate that other components depend on /bin/bash, as with minor
modifications one could use other shells and save /bin/bash's
inclusion to the initramfs image.)
* /scripts/local-top/clevis: some bits look quite brittle, for
instance
psinfo=$(ps) # Doing this so I don't end up matching myself
echo "$psinfo" | awk "/$cryptkeyscript/ { print \$1 }" | \
and
local $(grep '^CRYPTTAB_SOURCE=' /proc/$pid/environ)
I believe that cryptroot-unlock's approach [0] is a lot more robust.
* /scripts/local-bottom/clevis: `ps -l` output is not meant to parsed,
and differs between implementations — in particular between busybox's
and procps'. The initramfs-tools hooks will install busybox to the
initramfs image if available, so one shouldn't use `ps -l` at
initramfs stage.
If $pid is a process group leader and its children aren't (didn't
check if that's the case) then `kill -$pid` is enough. Otherwise,
more robust ways to list its children include
ps -eo pid= -o ppid= | sed -nr "s/^\\s*([0-9]+)\\s+$pid\\s*$/\\1/p"
or alternatively, using the proc(5) pseudo-filesytem directly
sed -nr "s/^([0-9]+) \\(.*\\) \\S $pid \\1 .*/\\1/p" /proc/[0-9]*/stat
(Neither alternative includes grandchildren, though.)
Cheers,
--
Guilhem.
[0]
https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/master/debian/initramfs/cryptroot-unlock
signature.asc
Description: PGP signature
