[pkg-cryptsetup-devel] Bug#714333: cryptsetup: several issues and questions all over the place

[Christoph Anton Mitterer]

Package: cryptsetup
Version: 2:1.4.3-4
Severity: normal


Hi Jonas.

Several small issues and questions all over the place you might have a look at:

1) README.Debian
a) For askpass you mention "(console, fifo, splashy, ...)" the "..." implies
that others are supported as well, but AFAIU this is not the case (e.g.
plymouth?!) so that should perhaps be removed to avoid any false hopes.

b) In the section about "Backup the LUKS header" I'd add that the plain master
key alone can also be backuped using --dump-master-key ... of course noting
that the user needs to protect it!

c) "10. Changing the boot order of cryptdisks init scripts"
It would be handy if you add information about which ("lvm on luks" and
"luks on lvm") is which init-script and for which you need the noearly option
in crypttab.
Also... on how to do this in initramfs... is this possible at all? There seems
to be an undocumented lvm option?
 

2) Not sure about that, in cryptroot hook
You doe some checks for the initramfs-tools.conf MODULES parameter
if [ "$MODULES" != "dep" ]; then
...
and
if [ "$MODULES" != "dep" ] || [ "$setup" = "yes" ]; then
...

as you check for ! dep ... this also includes "list" which is "defined" to be
"Only include modules from the 'additional modules' list"
So... don't we break this then?
Sure cryptsetup won't work it the modules aren't in that list... but well...
the user choose to.

Not sure about "netboot"... it says skip block devices... so in principle this
also means no cryptsetup, right? ... The only "netboot" kind I can imagine
where cryptsetup would apply is when using nbd... but not sure wheter
netboot includes that as well.


3) I'd urge you to reconsider what we've discussed some years ago:
Filesystems on top of dm-crypt devices must be specified via their
“/dev/mapper/*” pathname.
Using their LABEL, UUID or pathnames like “/dev/disk/by-label/*”,
“/dev/disk/by-path/*” or “/dev/disk/by-uuid/*” allows certain types of meta-
attacks as described here:
http://www.saout.de/pipermail/dm-crypt/2010-June/000856.html
Using their “/dev/disk/by-id/dm-uuid-*” pathname might be safe in some few
cases but should be avoided.

I've seen such a meta-attack in the wild just some weeks ago... unfortunately
I cannot (read "am not allowed to) give much details. :(

Nevertheless... I still think we should protect our users from such meta-attacks
because what they want the most is security... and not that the boot process
continues (within evil images).


4) The cryptroot script prereqs "cryptroot-prepare"... which is for custom
mods right?
AFAICS this nice feature is nowhere documented (at least a grep didn't find it ;) ).



I was quickly reading through all the initramfs code again,... but it's rather
complex in the meantime and I'm not fully sure about all things:

5) What works out of the box with respect to encrypted root/resume seems to be
physical->mdadm->LVM->dmcrypt->fs
right?

Does the following also work out of the box?
physical->mdadm->dmcrypt->LVM->fs

I've seen the lvm= parameter in the scripts,.. and the README.initramfs tells it would
be documented in the crypttab manpage but it is not?!
Or is that related to the previous scenario only?


Has "noeraly" any effect in initramfs? Cause for noeraly the manpage says
"once before lvm, evms, raid, etc. are started and once again after that"
but according to the PREREQS... cryptroot always comes last.
(and lvm2 PREREQS on mdadm)


6) With respect to resume device support... this is for disk hibernation, right?
Which is *THE* intended way now? uswsusp, swsusp or  initramfs-tools?
And is there a good way to verify whether the memory is really dumped into the
encrypted resume device and not overwritte plainly?


7) Do I understand this correctly, that in the cryptroot script,... you activate
all available lvms... I mean this is somehow lvm2's initramfs script's job...
(but that never worked and the maintainer was uncooperative)... is the reason
for your lvm activation to work around?


Last but not least... I've had a look at decrypt_gnupg again...
It still seems to be in any way inferior to what I made and presented some
years ago, with proper hooks that only add stuff the initamfs when it's really
used... and also support loading the key from removable devices... and it
comes with much documentation...
Have you perhaps changed your mind and would you reconsider it's addition to
the package?
Another alternative would still be the idea to have cryptsetup-<keyscript> packages
to keep the list of dependecies small.
Nobody really seems to bother such small packages anymore nowadays.

I'd also continue to maintain the scripts... but so far I never needed to
correct anything on them (but a typo in one of the comments).


Cheers,
Chris.