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

[Jonas Meurer]

Hey Zygo,

thanks for your feedback. See my comments inline below.

Am 02.10.2014 um 16:43 schrieb Zygo Blaxell:
>> 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.

Mh, interesting idea. You mean to prefix the encrypted data by an
identifying header on the plain device? The precheck could skip the
un_blkid check in case that this header is detected.

While this solution would be reliable for plain dm-crypt encrypted tmpfs
and swap partitions, it wouldn't work for any other plain dm-crypt
encrypted partitions - especially as users do use plain dm-crypt exactly
for the reason that it doesn't write an identifying header (plausible
deniabilty). That's my biggest argument against this solution.

Feel free to provide patches that implement that solution nevertheless.
I would be ok with adding these headers at default tmpfs and swap device
creation/detection logic as long as they and their impact are documented
properly.

> 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.

While that one might be easier to implement, plain dm-crypt devices that
don't provide a UUID would remain prone to the bug you discovered.
Container files (with loopback) and physical partitions on MSDOS
partition table come to my mind.

To me, the solution sound like a lot of added complexity compared to the
gain.

> 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.  ;)

That's the solution I like the most, it's the easiest one for me ;)

No, jokes aside. If detection of HFS actually can be improved in blkid,
then that should be done, regardless whether one of your proposed
solutions from above will be added to the cryptsetup package or not.

I'm sure that patches to util-linux package are appreciated :)

>>> 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.

You're correct. In case that checkfs.sh doesn't (try to) process the
missing filesystem, boot process isn't stopped. Mountall.sh seems to
warn about missing filesystems, but doesn't panic out. While I'm not
sure whether I like that, it's out of scope for this bugreport ;)

Kind regards,
 jonas