[pkg-cryptsetup-devel] Bug#906283: initramfs script expects file system on crypto device

[Guilhem Moulin]

Control: severity -1 wishlist

Hi Marc,

On Thu, 16 Aug 2018 at 16:50:55 +0200, Marc Haber wrote:
> Severity: normal

Lowering to ‘wishlist’ since AFAIK it's not the a regression; the check
is already place in 2:1.4.3-4 (stretch), 2:1.6.6-5 (jessie) and
2:1.7.3-4 (wheezy):

    https://sources.debian.org/src/cryptsetup/2:1.7.3-4/debian/initramfs/cryptroot-script/#L352
    https://sources.debian.org/src/cryptsetup/2:1.6.6-5/debian/initramfs/cryptroot-script/#L344
    https://sources.debian.org/src/cryptsetup/2:1.4.3-4/debian/initramfs/cryptroot-script/#L319

> I am not sure how to solve this since the behavior of the new script
> seems in order in most regular cases.

Hmm we want that check for `--type=plain` indeed: unlocking a plain
dm-crypt device with a wrong key will happily succeed and yield a mapped
device full of noise; so the check avoids to inadvertently run `mkfs` or
perform other writes that would erase existing (but invisible due to the
key mismatch) non-volatile data.

However, for `--type=luks` (and I guess other header types for which
cryptsetup(8) can use the metadata to verify whether the passphrase is
correct) that check seems unnecessary.  I mean, if the user forgot to
run `mkfs` / `mkswap` for devices that are required at initramfs stage,
then subsequent scripts in the boot process will fail, and it's not
really the job of our own scripts to prevent that (the boot process
would also fail on plaintext devices with unknown file systems).

So I'd be in favor of removing that check for device types other than
‘plain’, without even introducing a new crypttab(5) option.  On top of
my head, the only thing we would stop protecting against, is if the
header is replaced (with `luksHeaderRestore`) with another one where 1/
the same passphrase can unlock both, and 2/ the master keys differ.  In
that case, if the corresponding crypttab(5) entry has the ‘tmp=<tmpfs>’
or ‘swap’ options set, then existing non-volatile data might get lost.
Sounds quite an improbable scenario though.

Or did I miss something, Jonas? :-)

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180816/08d6ab3e/attachment.sig>