Most people would not dream of posting their company's business plan on Facebook. On laptops, however, people often carry their company's business plans around with them and leave them at a coffee shop. In a survey [1], 86 percent of IT security professionals revealed that at least one laptop had been stolen or lost in their company. In 56 percent of these cases, a data security breach occurred. Sixty-one percent of German IT professionals said that data loss is more serious than the material damage; only 13 percent would worry more about losing the hardware.

What Now?

Although conventional Linux laptops use modern filesystems like ext4 or XFS, which ensure the validity of the files, they store the data unencrypted – this is no obstacle to a data thief who has come into the possession of the device. Techniques such as TrueCrypt, however, store data in encrypted containers; in combination with a strong passphrase, this approach is considered safe. However, TrueCrypt cannot encrypt the entire Linux system.

In this article, I'll present a more-or-less fully encrypted system that runs on a heavily encrypted master partition. Only the small /boot partition with the kernel and initramfs remains unencrypted. The filesystem I'll be using is the feature-rich ZFS on Linux (ZoL [2]). The storage space can be distributed dynamically between all ZFS filesystems. ZFS also provides block checksums for data integrity and can compress files transparently, if needed.

Starting from a how-to by Matthew Thode [3], the following steps describe the not-always-intuitive path from the Live DVD to the encrypted production system. My choice of operating system was the 64-bit version of Gentoo Linux. I chose 64-bit because the 128-bit ZFS filesystem comes from the enterprise world of Solaris. Although it's in daily use, its developers still classify ZFS on Linux as a Release Candidate. For production operation, you need to take the usual warning more seriously here: Without regular backups, your data is in danger.

Preparing the System

The Gentoo installation is a manual process using the Live DVD and shell. The process is well documented in the usual style for this distribution [4]. The guide here is therefore limited to the basics. After booting from the Live DVD [5], define the partitions without GPT to keep things simple: a small boot partition (/dev/sda1), then /dev/sda2 for the rest.

Listing 1 shows the next steps. Line 1 formats /boot with ext2; line 2 creates a LUKS-encrypted device on the other partition. The passphrase you are prompted for at this stage should be robust because the security of your system depends on it in the future. The computer prompts you for the passphrase on booting and only opens the ZFS pool if it is correct. Incidentally, LUKS provides the ability to store multiple passphrases – for example, a master passphrase for the administrator and another for daily operation.

At the next step, LUKS opens the encrypted device with the passphrase. Line 4 now creates a ZFS pool on the block device. The options used set the sector size [6], clear the cache file, and provisionally mount the new rpool pool in a Gentoo-compliant way below /mnt/gentoo. The next block in Listing 1 creates a number of individual filesystems with somewhat different properties [7] in the ZFS pool. This works with ZFS features.

Instead of dividing the existing disk into partitions of fixed sizes, this setup uses the functionality of ZFS to manage the space as a pool. The available space on /dev/sda2 is equal to the size of the ZFS pool, rpool. In the pool, the admin then creates individual filesystems for the various directories of Gentoo Linux, partly with different properties (e.g., with transparent compression). Files written here are automatically and transparently compressed by ZFS.

The design and layout of these filesystems is just a suggestion; you will want to adapt this to suit your own needs by considering what ZFS features, in the form of properties, you want to define for the individual areas. It is possible to reserve space for the root user (reservation property) or limit the maximum space available to normal authorized users (quota property). For some areas, such as the compressed tarballs with the Gentoo packages in /usr/portage/distfiles, there is no point wasting processing power on compression, so the compression property is set to off here.

Other properties include sharing filesystems via NFS and space-saving deduplication of blocks; however, this does require RAM and other resources and is therefore not recommended for less powerful machines. Particularly critical data can be kept especially safe with the copies property: ZFS then stores each block several times. If a block no longer has the originally computed checksum during reading, the copies are still available, and it is very likely that at least one will be okay. Redundancy comes at a price of higher space requirements but without having to use multiple physical disks. (ZFS RAID functionality is not used in this article.)

ZFS is not only the filesystem but also the volume manager, like LVM 2. The advantage for the user is that you don't need to plan in advance exactly which directories occupy how much space, because you can change the assignments without repartitioning later.

Enabling ZFS Packages

The next steps are Gentoo standard: the wget and tar commands (Listing 1, lines 21 and 22) unpack a stage3 archive on the new system. A chroot environment is required for the others. The section starting in line 24 provides appropriate ZFS meta-information, and the admin then uses chroot to change to the new system. In this environment, you then install and configure the software.

The Gentoo developers classify ZFS on Linux as unstable. Hence, you must specifically allow several packages (in Gentoo speak, "unmask"). This also applies to the Solaris porting layer (SPL [8]), which is a collection of kernel modules that emulate Solaris APIs on Linux, so that the ZFS code created on Solaris encounters a familiar environment. ZFS on Linux thus works around some kernel functions that native Linux filesystems normally use.

To unmask the required RC packages, you can add the entries listed in Listing 2 to the /etc/portage/package.accept_keywords file.

During the boot process, the kernel automatically opens the LUKS device. To do so, it needs a statically compiled binary cryptsetup in its initramfs. This explains why Listing 3 sets the static use flag for the sys-fs/cryptsetup package and another couple of flags for packages on which cryptsetup depends in the /etc/portage/package.use file.

The command in line 1 of Listing 4 compiles and installs cryptsetup. When this article was written, Linux kernel version 3.5.7 was stable, and the patches by Matthew Thode, which he created for 3.5.0, could still be applied (see lines 2-6).