[Pkg-cryptsetup-devel] Bug#465902: Bug#465902: cryptroot remote unlocking on boot feature

[debian at x.ray.net]

hi!

jonas wrote:
>>> 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.

david wrote:
> 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 
cryptroot-script).

> 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 
now... :)

> On an unrelated note...what host key does the dropbear daemon use in the
> initramfs?

in the current dropbear patch the mkinitramfs takes the host- and 
authentication-keys from /etc/initramfs-tools and copies them to the 
initramfs.
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 
known_hosts).

	Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cryptsetup_2:1.0.6~pre1-1.x.diff
Type: text/x-patch
Size: 2735 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20080227/27f4b9b6/attachment.bin