1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
SPELL=cryptmount
VERSION=4.0beta1
SOURCE="${SPELL}-${VERSION}.tar.gz"
SOURCE2=$SOURCE.sig
SOURCE_URL[0]=$SOURCEFORGE_URL/${SPELL}/${SOURCE}
SOURCE2_URL[0]=${SOURCE_URL[0]}.sig
SOURCE_GPG=B8CEF5E7.gpg:$SOURCE2:UPSTREAM_KEY
SOURCE2_IGNORE=signature
SOURCE_DIRECTORY="${BUILD_DIRECTORY}/${SPELL}-${VERSION}"
WEB_SITE="http://cryptmount.sourceforge.net/"
LICENSE[0]=GPL
ENTERED=20090317
SHORT="a utility which allows an ordinary user to mount an encrypted filesystem"
cat << EOF
There are currently two main approaches to using encrypted filesystems within
the linux kernel:
* the cryptoloop device driver;
* the device-mapper system, using the dm-crypt target.
The (older) cryptoloop system has grown in parallel with the loopback
device-driver of 2.4 kernel series, but has now been superseded by
the device-mapper capabilities of the 2.6 kernel series. The newer
devmapper system offers a cleaner organization of encryption and
device-access, and superior performance has been noted. Alternative
user-space tools which allow individual files to be encrypted are
also widely available, but allow some information about file sizes &
organization to be exposed.
With the older cryptoloop system, it was possible to describe all
the details of an encrypted filesystem within /etc/fstab so that it
could be configured completely by 'mount'. This meant that it was
particularly easy to give any user permission to mount those encrypted
filesystems simply by providing the 'user' option within /etc/fstab.
With the newer device-mapper infrastructure, there are more stages
involved in mounting an encrypted filing system, and neither does
'mount' currently allow this nor does the syntax of /etc/fstab lend
itself to describing all the necessary filesystem parameters. This
is especially so if the filesystem is stored in an ordinary file,
which would require separate configuration of a loopback device and
a devmapper target before the filesystem could be accessed.
cryptmount was written to make it as easy for ordinary users to
access encrypted filesystems on-demand using the newer devmapper
mechansism as it was to use the older, now deprecated, cryptoloop
methods. This offers the following advantages:
* access to improved functionality in the kernel
* transparent support for filesystems stored on either raw
disk partitions or loopback files
* separate encryption of filesystem access keys, allowing
access passwords to be changed without re-encrypting
the entire filesystem
* storing multiple encrypted filesystems within a
single disk partition, using a designated subset of
blocks for each
* rarely used filesystems do not need to be
mounted at system startup
* un-mounting of each filesystem is locked
so that this can only be performed by the
user that mounted it, or the superuser
* encrypted filesystems compatible
with cryptsetup
* encrypted access-keys can
be chosen to be compatible with
openssl, or managed via libgcrypt,
or (for 2.0 release-series) built-in
SHA1/Blowfish ciphers
* support for encrypted swap
partitions (superuser only)
* support for setting up
encrypted filesystems or
crypto-swap at system boot-up
EOF
|
