[pkg-cryptsetup-devel] crypsetup: continues even if enter wrong password

[Jonas Meurer]

Hey Douglas,

On 26/11/2008 Douglas A. Tutty wrote:
> I pulled your name/email from the end of the README.Debian for
> cryptsetup.  I'm running Etch i386 on my home box.  Because of the
> security situation in our apartment building, I need to protect our
> private data from someone snatching the computer (I have backups
> encrypted with openssl and off-site backups).  To this end, I had the
> installer encrypt swap, /var/local, /var/tmp, and /home (/tmp is on
> tmpfs).
> 
> I note that if you enter the wrong LUKS password, the setup script
> prints and logs that the operation failed, yet the boot proceeds.  (I
> did this just to see what happens).  I put "check" in crypttab, but the
> same thing happens.

The check script is not supposed to stop boot process in case that it
fails, but rather to verify that the decrypted dm-crypt device has the
expected content (= filesystem). This is especially useful if you have
plain dm-crypt mappings (without LUKS), as there exists no check whether
the given passphrase/keyfile was correct. The mapping is always created.
Only possibility to verify is the content on the decrypted device.

> So, I said, so what?  I did this a few times.  The problem is that if
> the filesystem is set to be checked (e.g. you shutdown with hF), then
> the a filesystem check is forced yet the data isn't really a filesystem.
> Sometimes fsck craps out and you get asked for the root password and you
> can just shutdown -r now.  However, once it didn't crap out and treated
> the (wrongly) decrypted partition as a badly corrupted ext3 filesysem
> and thoroughly hosed it.  Luckily, this was in initial testing (playing)
> so no data was lost and I just reinstalled.
> 
> I'm wondering why a failed setup doesn't result in a suspending of the
> boot process, or at least of not setting up a device so that the fsck
> can't find the device to then corrupt?

It's a good question, but at least it's not the duty of cryptsetup to
suspend the boot process when a dm-crypt mapping failed. If you want
your system to completely fail in case of a wrong passphrase or keyfile,
you should use encrypted root filesystem. Otherwise all services which
don't rely on one of your encrypted filesystem will successfully start.

I see your problem, but I don't know a solution to it yet. And after all
cryptdisks is just one initscript out of several, which may or may not
fail. Just like any other service you start during boot process. And
it's good design to continue with boot process if a service fails to
start.

I hope that this answers your questions.

greetings,
 jonas