linux-ext4 - Re: Patch to support LUKS UUIDs in libblkid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070621175618.GA22285@thunk.org>
Date:	Thu, 21 Jun 2007 13:56:18 -0400
From:	Theodore Tso <tytso@....edu>
To:	Karsten Hopp <karsten@...hat.com>
Cc:	linux-ext4@...r.kernel.org, dm-crypt@...ut.de
Subject: Re: Patch to support LUKS UUIDs in libblkid

Thanks, I've applied the blkid LUKS patch to the e2fsprogs SCM (modulo
a minor whitespace breakage which I fixed up).

BTW, there appears to be a problem here in udev regarding LUKS
identification:

https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/93921

The problem is that udev sets its magic string in the first 512 bytes
of the partition.  This is dangerous and error-prone, because other
things like boot sectors and BSD disk labels tend to live in the first
512 byte sector.  Hence, many programs are very careful before zapping
the first 512 byte sector.  LUKS was added to the vol_id program very
high in the list of filesystems to be probed, ahead of ext2/ext3, so a
filesystem previously contained a LUKS setup, but then was later
mke2fs'ed to be used as a normal ext2/3 filesyste, may get
misidentified by udev's vol_id as still being a LUKS filesystem if
other fields in the first 512 byte sector cause mke2fs to mistakenly
think there was a BSD disklabel in the sector and thus refuse to zero
it out.

This won't be a problem with blkid, since LUKS is placed *after*
ext3/4.  However, it would be a good idea to check and make sure that
whever is setting up a LUKS partition clears the first and last 32k of
a filesystem, to avoid potential confusion by other in-band filesystem
type checkers.  It would probably be a good idea to (after you make
sure this is done) to submit a patch to the uev folks changing the
probing order of vol_id so that it probes for the LUK filesystem after
ext2/3.   

I am currently consider adding specific kludges to mke2fs that checks
the first couple of bytes of the 512 byte sector for the problematic
filesystem types (NTFS and LUKS), explicitly clearing just those bytes
to avoid future confusion.  But that won't help the existing
filesystems that are out there....

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html