[dm-crypt] nuke password to delete luks header
florian.junghanns at gmail.com
Thu Jan 16 14:09:49 CET 2014
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... :-)
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 at redhat.com> 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.
More information about the dm-crypt