[Pkg-cryptsetup-devel] Bug#371135: About Bug#371135: suggestion

[Mika Bostrom]

>On 08/06/2006 David Härdeman wrote:
>> I suggest that we use the following logic:
>> 
>> 1) do vol_id check
>> 
>> 2) if fstype is swap, we're done
>> 
>> 3) if fstype is known, complain and exit
>> 
>> 4) if fstype is unknown, run mkswap
>
>yes, but initially the idea was to only check where we can be absolutely
>sure that the check has no corner cases.

  I claim that this is impossible. There is no way to be absolutely sure
about non-destructiveness of the operation. I'll try to explain.

>imagine the scenario that /dev/hda2 is your uncrypted homepartition, and
>for some stupid reason you add it as an encrypted swap partition with
>random key to /etc/crypttab.

  This is something that can't be prevented at all if static filesystems
are encrypted as well. See below.

>in this case we will never find a known fstype on the cryptsetup target
>device, as the random key will always differ.
[...]
>- check per default only if we might destroy data
>- check per default only if the check is secure, has no corner cases
>- support any other kind of check, but don't activate it per default

  With changing keys there is absolutely no way to identify what is
valid swap space area. I see two possible approaches that _might_ be
_theoretically_ doable:

  1. If crypttab defines an encrypted swap, use vol_id check for both
     the created mapping AND the actual device.

  2. Use Jari Ruusu's watermark attack and explicitly disallow ESSIV
     encryption mode for swap.


  Trouble with case 1 is that it still does not catch a human error: The
user could have fe. encrypted /home along with swap, and mixed the
devices for these two lines. The additional test only catches the case
that encrypted swap is erroneously defined on top of an unencrypted
filesystem. 

  The problem with case 2 is that I have no idea how difficult it
would be to watermark swap space and still keep it completely usable.  I
also do not even like the idea of using a cryptanalytic attack and
intentionally weakening encryption for any protected area. 

  So the two practical approaches that I see, are: allow users to hang
themselves, or do not allow automatically used encrypted swap at all.

  Sure, you could add yet another test for partition size and require
that for encrypted swap the size of the swap is given. This doesn't
sound too practical, and still does not provide absolute protection
against human errors - I could have 4G swap and 4G encrypted /usr/local.
In which case the issues of case 1 are present again. You can't use
partition type either, as swap could be a file.

  With all due respect, I do not see how you could possibly prevent the
users from damaging their setups in all possible cases.

  Thanks,

-- 
 Mika Boström      +358-40-525-7347  \-/  The flogging will
 Bostik at iki.fi    www.iki.fi/bostik   X   continue until
 Security freak, and proud of it.    /-\  morale improves
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20060616/c2bfb913/attachment.pgp