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 /.
signature.asc
Description: Digital signature
