On 01/16/2014 11:30 AM, Thomas Bastiani wrote:
Hi guys,
I've been following this discussion for a few days. And I feel like giving
my opinion... :-)
Hello everyone,
I'm feeling the same way as Thomas does. Please see below for my
explanation and proposal.
On 16 January 2014 09:50, Ondrej Kozina <okozina@xxxxxxxxxx> wrote:
On 01/15/2014 09:27 PM, Milan Broz wrote:
[...]
But what I really want to avoid is that every distribution will
add some random patches implementing something like this.
It is perhaps better to implement and document this upstream.
I would argue that it's really independent from any actual crypto logic.
The only thing that need's to be done is wrap the password/key prompt and
check the password against a known salted hash or PBKDF (same as all Linux
distros do). Then "nuking" the container is actually quite simple. Just
erase the LUKS header by zeroing it. This is not any more complex than what
distros already have to do to support root-on-LUKS.
Actually this functionality is simple enough that anyone actually wanting
it can just write their own password prompt wrapper script.
I would point out that this doesn't require any more information from LUKS
internals than mouting a block device from /etc/crypttab would. And so it's
entirely possible to keep the code layered and simple. KISS applies.
Moreover, I think it's wrong to assume that distros don't share any of
their code. Proof is, they fork each other. It wouldn't have to be
implemented a dozen times.
It is my opinion as well that this should be solved by external wrappers
of the Linux distribution used. Also, I do not see how this is a
different area than e.g. caching the passphrase for mounting multiple
encrypted volumes on boot, a functionality that is provided e.g. by the
Debian distribution (not by dm-crypt). The functionality to make the
LUKS header unusable is provided by the 'dd' command with correct
parameters. IFF you want to provide the functionality of making the LUKS
header unusable via dm-crypt, I believe the *addition of a 'force' flag
to luksHeaderRestore* in order to enable a file that is not a LUKS
header backup file to be used as source is more sensible, e.g.
*'cryptsetup luksHeaderRestore /dev/sda1 -f
--header-backup-file=/dev/zero'*. This is a clear maintenance operation
which is - in my opinion - a saner solution than adding this very
unusual 'nuke' functionality. If you're still going to implement it, I
strongly feel it should be called something like 'destroy' instead of
'nuke'. Even better would be 'overwrite' or 'disable', since - as
discussed before - on e.g. SSD drives this does not necessarily 'nuke'
the header rather than 'displace'/'unlink' it from the former position
in the block register.
As already indicated above, I feel that this is a maintenance operation.
Without putting yourself in danger, there are two use cases when you
will want to 'nuke' your header. The one is before you depart from your
original location. Then you have your device booted and can use the
normal system tools ('dd', or - if the -f flag is implemented -
luksHeaderRestore) to disable the LUKS header. The other situation is
that you are short on time and cannot manage to boot your device without
e.g. missing your flight. In that case, you need the option to disable
the header without actually booting the device. This however is not the
core functionality and responsibility of dm-crypt but rather of the
distribution in use which can do this with a wrapper script just like
Debian does already for caching passphrases.
Any other use case I can think of is - as discussed to some extent in
the last few days - either stupid or heavily endangering yourself or
both. It is not the task of dm-crypt to enable people to do such things.
Best regards,
Florian
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
