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

[Zygo Blaxell]

On Tue, Oct 07, 2014 at 07:24:37PM +0200, Jonas Meurer wrote:
> Am 02.10.2014 um 16:43 schrieb Zygo Blaxell:
> > 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[...]
> 
> 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.

Yes.  The presence of the header would state positively that the
partition is intended for use with a tmpfs, as opposed to relying on
each of the growing list of blkid tests to provide a negative result
when fed random data.

It fits well with tools that rely on blkid to identify partitions.
tmpfs/swap encrypted partitions are currently not recognized
automatically, but everything else is (except for plain dm-crypt
non-tmpfs, which is intentionally unrecognizable).

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

I wouldn't expect the new header to be used for non-tmpfs partitions.
cryptdisks_start would not need to format the partition, and once the
partition is correctly decrypted it will most likely have a signature
that can be recognized by blkid (not to mention the mount or swapon).
We already have LUKS when there is a need for identification prior
to decryption.

The new header would mean "this partition is safe to format and use for
irretrievably encrypted data with a random key" in a way that blkid
can distinguish from other recognized parition types with certainty.
It's a special case that is only needed for encrypted tmpfs and swap.

> Feel free to provide patches [...]

Any ideas on a header format?

LUKS headers provide most of what we need--places to store key size,
cipher, data offset, and other parameters, and it's already recognized
by blkid.  It could be as simple as extending cryptsetup to store and
understand "Hash spec: random" (instead of the usual sha1) and load a
random key instead of processing key slots.

On the other hand, getting those changes into cryptsetup might not
be simple.

> > 3.  blkid could be more strict about identifying a HFS filesystem to
> > avoid false positives[...]
> 
> 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 could make an attempt, but I don't have any real HFS filesystems
to test with, and I'd worry about false negatives too.  I could use
Linux fs/hfs code as a reference but I'm not even sure blkid and Linux
completely agree on what a HFS filesystem is.  I'd prefer to leave that
to someone who knows what they're doing.

Also there would still be a small probability of failure.  Some blkid
recognizers look at 32 bits, which could still fail a few times in a
very large user population.

-------------- 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/20141007/290e2e73/attachment.sig>