[Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails

[Mika Bostrom]

Package: cryptsetup
Version: 2:1.0.3-2
Severity: normal

  Using a variable (boot-time generated and unknown) key for encrypting
swap space triggers a failure. The net effect is that swap space is
never used. Below are included the relevant snippets and/or files and
the annotation for what I believe to be the reason for this behaviour.


% cat /etc/crypttab 
# <target name> <source device>         <key file>      <options>
cswap   /dev/hda7       /dev/urandom    swap,cipher=aes-cbc-essiv:sha256
ctmp    /dev/hda8       /dev/urandom    tmp,cipher=aes-cbc-essiv:sha256


% grep mapper /etc/fstab 
/dev/mapper/ctmp /tmp           ext2    defaults        0       2
/dev/mapper/cswap none          swap    sw


  With the above setup the swap space is not taken into use when
booting. I believe the reason is this, as seen in changelog.Debian.gz

  * add new check 'vol_id', which uses /lib/udev/vol_id from udev and supports
    checks for any known filesystem type. implement a new option checkargs in
    cryptdisks for that. suggest udev. closes one half of #370302. thanks to
    Markus Nass and Darvid HÀrdeman for the suggestion.
  * always check for a swap partition before running mkswap

  The sequence during boot goes like this:

  1. /etc/init.d/cryptdisks is run; it in turn uses
      /lib/cryptsetup/cryptdisk.functions
  2. in cryptdisk.functions:parse_opts option 'swap' causes
      /lib/cryptsetup/checks/vol_id to be used before doing anything to
      swap{space,device,file}
  3. in cryptdisk.functions:do_start the sequence of operations is:
     - parse_opts
     - [...]
     - do_luks / do_noluks
     - do_swap
  4. cryptdisk.functions:do_luks creates the cryptographic mapping layer
      with given key; As this key is read from /dev/{,u}random, the
      mapping is different each time the operation is run
  5. The test with /lib/cryptsetup/checks/vol_id naturally fails, since
      the key has changed --> mapping is removed!
  6. in cryptdisk.functions:do_swap the mkswap command is now guaranteed
      to fail; since the mapping was removed in previous step, there is
      no longer /dev/mapper/$dst in place
  7. swapon -a naturally fails

  Hence, to get encrypted swap in use after boot, it is required to
manually enter the following commands:

# cryptsetup -c aes-cbc-essiv:sha256 -h sha256 \ 
  -d /dev/urandom create cswap /dev/hda7
# mkswap /dev/mapper/cswap
# swapon -a

  The fix for this (common) corner-case is to ignore the test result for
'vol_id swap' if keyfile is not static. However, since some mislead
individuals may use a real keyfile for this purpose, I am not sure how
to make this test a proper and robust one. Perhaps test for keyfile's
type for chardevice first?

  A silver lining though, /tmp is recreated and used properly :)

  Thanks,

-- 
 Mika Boström      +358-40-525-7347  \-/ "World peace will be achieved
 Bostik at iki.fi    www.iki.fi/bostik   X   when the last man has killed
 Security freak, and proud of it.    /-\  the second-to-last" -A.H.(!)
-------------- 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/20060607/504ef48c/attachment.pgp