Re: Avoiding fsck.ext4 destruction of crypto_luks data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 28, 2012 at 08:22:25PM +0100, Milan Broz wrote:
> On 12/28/2012 04:04 PM, Arno Wagner wrote:
> > I am thinking about a "basic LUKS setup" section for the FAQ 
> > that is more in the nature of a mini-howto. Things like blanking
> > a previously used partition before a LUKS install seem to be 
> > not obvious to many people. Step-by-step instructions may help.
> 
> Wiping (whole) device (with some crypt random way) is still on TODO list.

You can just wipe with zeros on the mapped device. They will be
encrypted after all. That could leak a tiny bit of information 
to an attacker that has access to the encrypted container
multiple times, but such an attacker can likely do far worse 
things anyways. If that is a concern, just use a different
master key for the zero-wipe, e.g. a one-time key derived in the 
same way as the LUKS master key. 

> But I believe that common signatures are wiped during LUKS format already
> (we had several bugs related to this already) so it should never
> happen that device contains ext4/swap/whatever signature parallel with
> LUKS. (If so, please let me know, it is a bug.)

Ext2 superblock signatures are all not wiped. Test I ran:

-----
# head -c 100M /dev/zero > test
# losetup /dev/loop0 test
# mke2fs -q /dev/loop0
# hd /dev/loop0 | grep "53 ef"
00000430  8b 7d de 50 00 00 18 00  53 ef 01 00 01 00 00 00 |.}.P....S.......|
00800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
01800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
02800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
03800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
04800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
# cryptsetup luksFormat /dev/loop0
[...]
# hd /dev/loop0 | grep "53 ef"
00009970  53 ef 3d 36 73 85 da 1e  20 cb bc 48 e9 e3 d9 b6  |S.=6s...
# ..H....|
00012c80  a2 f1 f6 53 ef b9 0c 30  75 60 6c c5 14 0b 6a 6b |...S...0u`l...jk|
00800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
01800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
02800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
03800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
04800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|

-----
The 5 superblock backups are still there. That should at least make 
e2fsck require some kind of override option. However, the primary 
superblock is just between the LUKS header and first keyslot. If I 
remember correctly, older versions of cryptsetup did not wipe that 
area (1.5.1 does). Maybe that is what happened here. 

As for the superblock backups, I would say wiping them should be 
part of a full device wipe to be done on a previosuly used partition. 
I just added a "LUKS Container Setup mini-HOWTO" in the FAQ as item
2.1 that explains this. (That this is a TODO for cryptsetup also
noted.)

> fsck can possibly use blkid and warn user
> "Warning: device seems to contain xyz signature, do you really want...."
> but this is feature for fsck (util-linux), not for cryptsetup.
> (Anyway, I can ask util-linux maintainer later next year:)

That would be nice. Things are pretty safe right now, but
further improvement is always welcome.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@xxxxxxxxxxx
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux