Protecting filesystems and swap space with Cryptmount

1020

Author: Ben Martin

Cryptmount allows you to encrypt both your filesystems and swap space. An encrypted filesystem can be stored on a block device like a normal filesystem — for example, using /dev/sda2 — or inside a normal file in another filesystem. This later method is especially handy when you would like to work with an encrypted filesystem without changing your partition tables or working with the Logical Volume Manager (LVM). Cryptmount can also encrypt your swap space so that information from an encrypted filesystem is not inadvertently made less secure by the Linux kernel swapping a process out to disk.

The encryption Cryptmount sets up is performed in the Linux kernel at the device mapper level. This means that you can create any supported filesystem type on top of the encrypted device mapper block device file. Cryptmount handles setting up the device mapper encryption and mounting the filesystem that lives on top of the encrypted device mapper layer. Simple use of Cryptmount doesn’t require you to know about any of these details, however.

Cryptmount is packaged in Ubuntu Gutsy Universe and is available for Slackware and Gentoo in various forms. There is also an RPM file on the Cryptmount SourceForge.net page which you can use to install on Fedora 8.

The simplest way to get started using Cryptmount is with the interactive script cryptmount-setup. It lets you quickly create an encrypted filesystem in a single file. The defaults for cryptmount-setup are geared towards creating a directory under /home for encrypted content.

# cryptmount-setup ******************************** * cryptmount setup script * * This program will allow you to setup a secure filing-system that will * be managed by "cryptmount". You will be able to select basic features * such as the location and size of the filesystem - if you want more * advanced features, you should consult the cryptmount manual page. * ... Please enter a target name for your filesystem [opaque]: my-encrypted-files Which user should own the filesystem (leave blank for root) []: Please specify where "my-encrypted-files" should be mounted [/home/crypt]: Enter the filesystem size (in MB) [64]: 256 Enter a filename for your encrypted container [/home/crypto.fs]: Enter a location for the keyfile [/etc/cryptmount/my-encrypted-files.key]: ... enter new password for target "my-encrypted-files": confirm password: Formatting encrypted filesystem... enter password for target "my-encrypted-files": Your new encrypted filesystem is now ready for use. To access, try: cryptmount my-encrypted-files cd /home/crypt After you have finished using the filesystem, try: cd cryptmount --unmount my-encrypted-files # cryptmount my-encrypted-files enter password for target "my-encrypted-files": e2fsck 1.40.2 (12-Jul-2007) /dev/mapper/my-encrypted-files: clean, 11/65536 files, 18561/262144 blocks # df /home/crypt Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/my-encrypted-files 253871 10288 230476 5% /home/crypt

Take note of the cryptmount --unmount message. Although the Linux kernel will see /home/crypt as just another filesystem, you shouldn’t umount /home/crypt, because Cryptmount will still consider it to be active. If you do, the kernel filesystem would be unmounted, but Cryptmount would not let you remount it and will give you the message, “create ioctl failed: Device or resource busy.”

Once the filesystem is unmounted, you cannot issue the correct cryptmount --unmount my-encrypted-files command either, because Cryptmount will tell you that the filesystem does not appear to be mounted. The solution is to use the --release option to tell Cryptmount to release resources associated with a cryptmount that has already been unmounted by other means.

In the above session the encrypted filesystem is using ext3. You can specify the filesystem (ext2, ext3, XFS, etc.) to use, along with other options, inside the /etc/cryptmount/cmtab file. The above invocation of cryptmount-setup will have created an entry in cmtab for us already:

$ cat /etc/cryptmount/cmtab ... # entry automatically generated by setup-script: my-encrypted-files { dev=/home/crypto.fs dir=/home/crypt fstype=ext3 fsoptions=defaults cipher=aes keyformat=builtin keyfile=/etc/cryptmount/my-encrypted-files.key }

The dev option specifies the name of the block device or the filename where the encrypted filesystem is to be stored. The dir option is where to actually mount the encrypted filesystem. The type of filesystem is specified with the fstype, and fsoptions specifies the filesystem options in the same manner as in fstab. Keyformat and location are fairly straightforward. For a full description see the cmtab manual page. Another option specified here is to store the keyfile itself on a USB flash drive so that you can keep the key separate from the machine it unlocks.

The cipher option lets you choose which encryption algorithm to use for your Cryptmount filesystem. The default is AES, which should be fine for almost all users. The commands shown below display the ciphers that are available for the kernel you are running. If you have some encryption either built into your kernel or in a currently loaded kernel module, it will show up in /proc/crypto. To see which options are available for a kernel module, use modprobe to load it and check its information in /proc/crypto.

$ ls -l /lib/modules/$(uname -r)/kernel/crypto/ $ cat /proc/crypto ... $ sudo modprobe twofish $ cat /proc/crypto name : twofish driver : twofish-generic module : twofish priority : 100 refcnt : 1 type : cipher blocksize : 16 min keysize : 16 max keysize : 32 ...

The cryptmount-setup script must be run as root, as must most other commands that perform the same work as the script. The process of manually setting up an encrypted filesystem is shown in the cryptmount man page, so in this article I’ll put a slight variation on it by changing some options and targeting an encrypted filesystem stored entirely in the user’s home directory.

I’ll set up a 64MB encrypted filesystem which will be mounted inside my home directory using the XFS filesystem. As regular users cannot specify another cmtab file path, we’ll have to edit the global /etc/cryptmount/cmtab and place our Cryptmount information in there. The --generate-key option specifies the desired key size in bytes. In this case I want a 256-bit (32-byte) key. This is where the min and max keysize from /proc/crypto are relevant; you must use a value within that reported range. The --prepare option will have cryptmount set up all device mapper files for the filesystem but not actually mount it. This is exactly what we are after, so that we can create a filesystem on the device mapper supplied device file. As we have seen above, calling --release will get cryptmount to release any resources and device mapper files for a filesystem, letting us start clean on the next line getting cryptmount to mount the (recently created) filesystem. Still as root, we modify the protection of the root directory of the filesystem to allow the ben user to read and write to it and unmount it again. At this point the ben user can freely mount, interact with, and unmount the encrypted filesystem.

$ dd if=/dev/zero of=~/myencfs.fs bs=1M count=64 $ mkdir -p ~/myencfs $ su -l # vi /etc/cryptmount/cmtab ... home-ben-myencfs { dev=/home/ben/myencfs.fs dir=/home/ben/myencfs fstype=xfs fsoptions=noatime keyfile=/home/ben/myencfs.key flags=user,nofsck } ... # cryptmount --generate-key 32 home-ben-myencfs # cryptmount --prepare home-ben-myencfs # mkfs.xfs /dev/mapper/home-ben-myencfs # cryptmount --release home-ben-myencfs # cryptmount home-ben-myencfs # chown ben.root myencfs # chmod 700 myencfs # cryptmount -u home-ben-myencfs # exit $ cd ~ $ cryptmount home-ben-myencfs $ df ./myencfs Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/home-ben-myencfs 60736 3436 57300 6% /home/ben/myencfs $ cd ~/myencfs $ cp /tmp/linux-2.6.23.tar.bz2 . $ ls -l -rw-r----- 1 ben ben 45488158 2008-02-01 21:08 linux-2.6.23.tar.bz2

The contents of the swap file on disk do not need to be preserved between one mounting and the next, so we can use random data as the key that protects the swapfile. Each time the swapfile is mounted again, the script chooses a new random key and recreates the swapfile with mkswap. This avoids having to remember a passphrase for the swapfile. The down side of a random key is that we can never recover the contents of an unmounted swapfile, but we are not interested in doing that, so we can just use the /dev/random file for our key.

The code segment below will create an encrypted swapfile in the file /var/swapfile. In this case it is only 32MB of swap, but if the initial dd command were changed to create a 16GB file, then the remaining commands would create a huge encrypted swapfile.

# dd if=/dev/zero of=/var/swapfile bs=1M count=32 # vi /etc/cryptmount/cmtab ... swapfile { dev=/var/swapfile fstype=swap flags=mkswap cipher=twofish keyfile=/dev/random keymaxlen=16 keyformat=raw } ... # free -m ... Swap: 0 0 0 /usr/bin/cryptmount --swapon swapfile # free -m ... Swap: 31 0 31 # /usr/bin/cryptmount --swapoff swapfile

Because the cmtab lists swap mounts as fstype=swap, you might attempt to mount an encrypted swap partition without using the --swapon option. This mistake will lead to a page of complaints from the mount command and no encrypted swap partition. Although the fstype is swap, you have to use the --swapon option to mount encrypted swapfiles. If you want to use a separate partition for encrypted swap, replace the path in the dev= line to point to the block device for your swap partition. Make sure not to list the swap partitions and files in /etc/fstab so that they don’t get set up twice!

There is no option in cmtab to mark mount points to be automatically mounted after a reboot. You must list the names of the cryptmounts that you would like to bring up at boot time in the /etc/default/cryptmount file. The two variables of interest are CM_BOOTFS for filesystems to bring up and CM_BOOTSW for encrypted swap to set up at boot time. The below commands set up both an encrypted filesystem and swap space. With the change to the configuration file in place, the cryptmount and cryptmount-early services are set to start at boot time. During boot up the system will prompt you for the passphrase for home-ben-myencfs (in this example; you’ll have your username on your system instead of “ben”) and then continue to boot. Both home-ben-myencfs and the swap will be mounted when the system has booted.

/root# vi /etc/default/cryptmount ... # list of swap targets to configure at boot: CM_BOOTSW="swapfile" # list of filesystem targets to mount at boot: CM_BOOTFS="home-ben-myencfs" ... /root# chkconfig --add cryptmount-early /root# chkconfig --add cryptmount /root# reboot

You can change the passphrase for an encrypted filesystem using the cryptmount --change-password option. This changes the password that is used to encrypt the key for the encrypted filesystem. As such the filesystem itself does not need to change.

Cryptmount is useful for protecting information on mobile devices running Linux. Knowing that both your home directory and swapfile are encrypted makes having your laptop stolen an inconvenience and perhaps a financial loss, but not necessarily a data leak. Of course you must select passphrases
that are resilient to dictionary attacks to protect information against somebody who wants the data more than the laptop (insert paranoia here).

Categories:

  • Desktop Software
  • Security