[Pkg-cryptsetup-devel] cryptsetup keyscript-framework / OpenPGP keyscript

[Christoph Anton Mitterer]

Greetings.

On Mon, 2008-06-23 at 20:59 +0200, David Härdeman wrote:
> It's good that you sent this to the cryptsetup list rather than as a bug 
> report as it is more of a discussion than a bug report.
Yeah,.. I choose bugreports for the other stuff,.. because I've thought
they'd be small and independent issues that could "easily" be solved ;)


> Perhaps because you address so many different topics in the same
> mail? 
> :)
Uhm,.. yeah :-D .... at least you seemed to have it read ;)


> To elaborate on the hint I gave before...my current preference would be 
> that if a keyscript is called without any parameters, it prints a list 
> to stdout of all applications it depends on, one per line.
I remember this,... the main problem is that current keyscripts use
simply $1 instead of looking for an option like [--]source <filename>.
Unfortunately I assume that you're not willing to change this, are you?

While I agree with you that printing out the deps when no parameter is
used at all I think that this might lead to new problems if we ever want
to extend the capabilities of keyscripts again (e.g. I can think of a
mechanism that the right keyscript is chosen automatically depending on
the key itself, thus a keyscript must be able to tell which key-types it
can handle).
Another reason against it is, that it breaks with the usage of
initramfs-hooks/scripts where "prereq" is expected...

I'd strongly suggest to keep it homogen with the hooks/scripts,... but
then we'd have the problem, that we either have to:
a) change the current way keyscripts work (use [--]source <filename>
parameter)
b) use prereq and don't allow people to use "prereq" as filename
c) use "" like you suggested.

Personally I'd prefer a),.. because I think there are not so much
scripts,... and I consider this to be the cleanest solution (consistency
with hooks/scripts).
Both b) and c) have the disadvantage that you cannot use "prereq" and/or
(at leas I assume this) "none" as filename.

However,.. you're the maintainer so it's your decision...


> If calling a keyscript with no parameters generates that list, we
> could 
> easily do a separate pass at the end of the cryptsetup initramfs hook 
> that does something like this:
> IFS='
> '
> for script in $(ls -1 "${dst}/where/all/keyscripts/are/"); do
> 	list=$($script)
> 	for item in $list; do
> 		copy_exec "$item"
> 	done
> done
I wouldn't suggest this! What you do here is simply copy_exec the
binaries that are printed by the keyscripts. This is less mighty than my
solution (where this would be done by separate scripts) because there
might be keyscripts, that need "more" than just copy_exec a binary.

Think of smartcard support for gpg,.. where you might not only want to
copy gpg and pcscd to the initrd,... but also scan for the right library
to be used (e.g. libccid or libtowkito or whatever)... ok stupid
example, but got the point?

And the same as above: To keep this consistent with the "normal"
initramfs-hooks, I'd suggest that the dependencies are other
hook-scripts (that solve the dependencies).


> A second change that I think might make sense to add is to set 
> environment variables with additional information (like cipher, 
> keylength, etc). Then keyscripts that are interested can use that 
> information in a backwards compatible manner.
That's surely a nice idea :-)
This remembers me to the tries/timeout thing....
Who is actually handling this now? They keyscript or someting
"above" (you've mentioned askpass or so?)?


> However, I'm not sure these changes are a good idea to do pre-Lenny as 
> large changes close to a release is generally a bad idea.
You could just upload them to unstable but not to testing?


> On a related note I also have C code for an additional keyscript which I 
> will add some time later (post Lenny perhaps) that combines the use of 
> askpass and passdev to take a passphrase from the user, hash it (using 
> e.g. sha256), get a file from a removable device, XOR the file and the 
> hash and use the combination of the two as a key for cryptsetup.
Sounds interesting....

>  This 
> would allow a two-factor key without having to add the weight of large 
> software such as openssl or gnupg to the initramfs.
Ok,.. while gpg/ssl and so,.. have the mainadvantage of being well
tested and widespread,... you idea is (IMHO) very interesting for the
use in embedded area or so,.. where gpg/ssl is probably not suited for
the initrd ;)


> >-> 6:
> >A few days ago, I've added a wishlist, where I've asked to include an
> >option in /etc/crypttab like dep= where one could specify a
> dependency.
> >This was denied ;)
> 
> Yes, it was a horrible solution :)
:'-(
:-P

> >mount_usb_stick 1>&2 #secure that it doesn't write to stdout
> >decrypt_openpgp "$1"
> >umount_usb_stick
> 
> passdev would do this..."passdev /dev/disk/something:/my/file | gpg 
> --blah --foo --bar --decrypt --readfromstdin --writetostdout"
1) First of all I don't think passdev is (better said "can be") generic
enough.
I assume it simply tries to mount the device-part from device:file in
crypttab, right?
This doesn't allow to use LABEL or UUID,... and it does not allow to
make things like "beep as soon as you can eject the key).
btw: Does it wait for the device to be created? (e.g. my USB-stick is
not yet inserted or detected by the kernel/udev - the later happened in
my setup,.. even though I'm booting from the very same stick)

2) It breaks the specification of the 3rd fiel in crypttab. (This could
and perhaps should be changed - I mean the specification for the 3rd
field)

3) Right now, you cannot combine it with a decrypt_* script, can you?
And you cannot write both in crypttab like keyscript=passdev
+decrypt_openpgp or so...

4) And on the other side,.. there might be lot of situations (mostly
when already booted) where all devices are already available...


> Only if you write your scripts in a non-clean manner...passdev
> already 
> solves this for you.
see above,.. and please explain me how I'd have to use this with my
decrypt_openpgp script?


> Incorrect...passdev already solves this for you.
:P :P :P ^^


> The current setup should be as secure as is currently feasible. Data
> is 
> piped to stdout by keyscripts and read from stdin by cryptsetup.
What happens when using passdev? I mean the data-flow?

> This 
> means the data passes through a pipe using kernel memory which is 
> (unless I'm mistaken) not swapped to disk.
I think so too,... but wasn't sure.

>  In addition, the initramfs 
> scripts run before swap is setup, so no swapping is possible. If run 
> after the initramfs stage, swap should be encrypted (debian-installer 
> has code to enforce it) so even if e.g. the keyscript application and 
> it's memory is swapped, that should be encrypted.
Of course... I've already written this,... but you'd still have "little"
security problems,.. e.g. when someone gains root,... and can dd
if=/dev/swapdevice...
Ok,..this would mean that he can also get your data anyway...
However,.. just wanted to say,... that I have a better feeling when the
key is nowhere written to (which is obviously the case)


> Portable logging is a bit of a problem right now. "askpass" helps in 
> some respects since it should handle password prompts in a generic 
> manner for you.
Is there any documentation for askpass??? ;P


> Using the lsb logging functions should also work both in 
> initramfs and sysv-init script situations...but it's not ideal.
And it probably doesn't support splashy/usplash/etc, does it?

>  Beyond 
> passphrase prompts you should really be able to rely on the additional 
> messages that the cryptsetup scripts print as much as possible...
You mean I could cut most of my messages? Which of these are already
handeled by cryptsetup's scripts? Probably decryption
failed/succeeded ??


btw and before I forget it:
How does cryptsetup and the scripts behave,.. I specify that a device is
encrypted (in crypttab),... and I present the correct key on boot (e.g.
via my USB-stick),.. but the filesystem is actually not encrypted?
Will it be simply mounted and everything continues?

If so, I consider this a possible grave security leak,... which hast to
be fixed.
Because an attacker (that has access to you hardware) could exchange it
with an unencrypted version,.. with en empty debian,.. that does nothing
than stealing your key (for example).


> >For (5 & 8) but also for other points (like deciding whether the key
> may
> >be written to "disk":
> 
> Your script should work for both initrd and non-initrd scenarios. 
> Therefore it should never write to "disk". Therefore it should not
> need 
> to know where it is running because it should always use worst-case 
> assumptions.
Yeah,.. my mean reason behind this was: If I'm in the inird... I could
use the /scripts/functions log-functions,... if not... I would use
echo..
So no way for this? Or a better way for logging?



Thanks so far,
Chris.