Package: cryptsetup Version: 2:1.0.3-2 Severity: normal [Repost with reportbug due to PEBKAC]
(Note: this coinsides with #342709 which deals with the same issues,
although bit differently.)
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 (and/or suspended laptop users) 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.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.14
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages cryptsetup depends on:
ii dmsetup 2:1.02.05-2.1 The Linux Kernel Device Mapper use
ii libc6 2.3.6-13 GNU C Library: Shared libraries
ii libdevmapper1.02 2:1.02.05-2.1 The Linux Kernel Device Mapper use
ii libgcrypt11 1.2.2-1 LGPL Crypto library - runtime libr
ii libgpg-error0 1.2-1 library for common error values an
ii libpopt0 1.10-2 lib for parsing cmdline parameters
ii libuuid1 1.39-1 universally unique id library
cryptsetup recommends no packages.
-- no debconf information
--
Mika Boström +358-40-525-7347 \-/ "World peace will be achieved
[EMAIL PROTECTED] www.iki.fi/bostik X when the last man has killed
Security freak, and proud of it. /-\ the second-to-last." -anon?
signature.asc
Description: Digital signature
