[pkg-cryptsetup-devel] Bug#762297: Bug#762297: cryptsetup: fails to create tmp filesystem due to false positive from blkid

[Zygo Blaxell]

On Thu, Oct 02, 2014 at 01:16:16PM +0200, Jonas Meurer wrote:
> Am 20.09.2014 um 22:07 schrieb Zygo Blaxell:
> > un_blkid is not a suitable precheck for plain dm-crypt 'tmp' or 'swap'
> > devices due to the potential for false positives from previous runs
> > on the same device.
> 
> That's really unfortunate. To my knowledge, you're the first one who hit
> this issue so far.

Yay I win!  ;)

Out of every million attempts to create a tmp filesystem there should
be about 31 failures.  I won't be the last.

> Unfortunately, no better solution than un_blkid is known to me to
> prevent serious data loss in case of device rearrangement or
> missconfiguration with plain dm-crypt devices and automated swap or
> tmpfs creation. Thus I'll mark the bug as wontfix.

There are at least three ways to fix this:

1.  Create an encrypted tmpfs header.  A simple static header (or a
stripped down LUKS header) can be unambiguously recognized by blkid or
even cryptdisks itself.  cryptdisks can offset the encrypted payload
by the length of that header.  Since the data is ephemeral there is no
backward compatibility issue.  For upgrades, run the existing un_blkid
check (it is the best we have so far, even though it's still bad),
then install the header when a few tmp FS is created and use the header
from then on.

2.  When the underlying devices are identified by UUID (or through some
layer that uses UUID, such as LVM or md-raid) the precheck can be skipped,
since rearranging devices will not change their UUIDs.  UUID has enough
bits to avoid random collisions.  un_blkid could detect this case the
same way lsblk does, and ignore false positives from blkid.

3.  blkid could be more strict about identifying a HFS filesystem to
avoid false positives.  It looks like blkid detects HFS after inspecting
only 16 bits of the block device, and it ignores implausible superblock
parameter values (there are plenty it could be checking).  HFS is an
obsolete filesystem, so the probability of encountering a real HFS in
the field is certainly less than the probability of a false positive
ID in random data.  Maybe the bug should be reassigned to the blkid
(util-linux) package.  ;)

> In case that you really know what you're doing, you can set
> precheck=/bin/true in the crypttab and prevent the precheck for
> particular plain dm-crypt devices that way.

This is what I have had to do.  Changing both CRYPTDISKS_CHECK and
CRYPTDISKS_PRECHECK to /bin/true in /etc/default/cryptdisks was not
sufficient.

> > This bug potentially leads to information disclosure in some
> configurations.
> 
> This is true for encrypted tmp filesystems if the rootfs is not
> encrypted. Still, the boot scripts print clear error messages and the
> boot process should fail in that case anyway. It should be obvious that
> things don't work as expected in that case ;)

That is not what happens.  There are error messages, but the boot process
continues past them.  The boot could be stopped by a fsck failure when
mounting the tmp filesystem, except that the fsck would normally be
skipped in that case (why would you fsck a filesystem you just created?).
The system operates normally except for leaking data and having the wrong
filesystem on /tmp.

If we weren't auditing the systems regularly, the first sign of trouble
in production would probably be an unexpected ENOSPC on /.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20141002/7a91a914/attachment.sig>