[Pkg-cryptsetup-devel] Bug#465902: Bug#465902: cryptroot remote unlocking on boot feature
debian at x.ray.net
debian at x.ray.net
Wed Feb 27 16:41:36 UTC 2008
>>> That would mean to have a 'killall cryptsetup' at the end of every
>>> >> cryptroot execution.
>> > right. i think that's ok.
> Not sure. It's ok in a common setup, but what about users who use custom
> scripts in their initrd which invoke cryptsetup as well. sure, sounds
> like a corner case, but I still don't like the idea to kill every
> cryptsetup process per default in cryptroot initramfs script.
actually the console cryptroot instance (or actually: all) should be
killed by the (shell) cryptroot instance after successful completion.
as this already means the boot process will continue, the killall
cryptsetup could be spared. but this means that in case of unlocking
from remote, this would produce a dangling cryptsetup... so i guess the
killall cryptsetup would still be nicer. theoretically there shouldn't
be any valid cryptsetups left after one of the cryptroots finished.
killing the cryptroots and their child processes would be most elegant i
guess, but i wasn't able to find such a solution with the means
available in initramfs...
also, in this scenario, the check for existence of the crypttarget isn't
necessary anymore, so this change can be spared too.
i attached a new patch according to this.
> The addition of "[ "`tty`" == "/dev/console" ]" I did not quite
> understand. What was the purpose there? Manual invocations of the
> cryptsetup initramfs script I assume?
correct. taking care the splash-stuff is done exclusively by the
instance running on the console.
> As for the rest of the patch, I am still not convinced.
the killall cryptsetup/cryptroot? while i, too, would certainly prefer
to kill exactly the pid of the cryptsetup i'm looking for, in the
absence of means allowing this (afaik), i personally think a killall
would be acceptable (and preferable to just letting cryptsetup hang
around doing nothing) at this point.
> On the other hand, I already have some code for a simple program (in C)
> that automatically uses usplash or console to get a passphrase from a
> user. Perhaps it is time to dust it off, add fifo as a third input method
> and add it to cryptsetup.
right, i guess in c this could be done, one thread could read from stdin
while another thread reads from the fifo. and atomicity/locking should
be less of an issue there.
> It should make writing keyscripts simpler and should allow this ssh
> support to be written as a keyscript...in addition, we could remove some
> special cases from the initramfs script as that binary could be used as
> the keyscript when no particular keyscript has been defined (meaning we
> always run a "keyscript" and can move some of the usplash special cases
> from the initramfs script).
right, in this case the 'calling cryptsetup and typing in the password'
case would be one (standard/default/shipped) keyscript (that's what i
meant by 'removing the non-keyscript cryptsetup part' from the
> I have exams on 4:th, 5:th, 6:th and 12:th of March, so I won't have time
> to hack on that for another week or two though (not intended to try your
> patience Chris :))
well, no prob for me, as i've got working packages (now even supporting
multiple crypttargets! ;) ) i'm using for etch and lenny installations
for quite a while now...
i just thought this is certainly an issue for quite some people out
there... i wondered what the cases-per-day rate of incidents where
somebody sits some hundereds or thousands of kilometers away from his
box that waits for his cryptroot passphrase at the console might be...
so i felt kind of obliged to provide the solution and the corresponding
amount of work to the community, too. i guess i can rest my conscience
> On an unrelated note...what host key does the dropbear daemon use in the
in the current dropbear patch the mkinitramfs takes the host- and
authentication-keys from /etc/initramfs-tools and copies them to the
if they aren't already there, the mkinitramfs run will create them.
i.e. the installer could create them on installation, they can be
exchanged as needed, and they don't change over mkinitramfs-runs.
to log in, the secret authentication key from /etc/initramfs-tools is
needed (and the hostkey should be compared/fingerprint checked/added to
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2735 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20080227/27f4b9b6/attachment.bin
More information about the Pkg-cryptsetup-devel