Life with Linux

For a variety of reasons I use Fedora Core 6 as my primary operating system, both at home and on my laptop. And for security reasons, I need to have my filesystem encrypted, so that in the event that my laptop is lost or stolen, my confidential data does not fall into the wrong hands.

Unfortunately, while Fedora Core 5 and 6 support an encrypted swap partition, it doesn’t yet support encrypted root filesystems. (Due to release timing, official support is currently targeted for Fedora Core 7.) However, that doesn’t mean it’s impossible. In fact, I’ve done it. This is the second of a two-part series on encrypting your Fedora Core system.

(Read Part 1: Encrypting your swap partition on Fedora Core)

Before we get started, I must make one thing perfectly clear: This code is still experimental, and it could eat your files for breakfast, your children for lunch, drink all your beer, or do worse things. It works perfectly for me, but I can’t be responsible for your system, especially if you screw something up yourself. So follow along carefully. Read through the whole thing once before trying it, so you know what to expect.

Currently neither the Fedora Core installer nor the Fedora Core installation media support encrypted filesystems, so in order to create an encrypted system, you will need an already installed system, as well as a second hard drive (or partition) large enough to hold all the files on your root partition. For this reason, it’s best to do this just after you install the system, as you won’t yet have any sensitive files on the computer. Even if you do, though, we’ll securely erase the drive to help prevent recovery of your data.

In addition, you’ll need a Linux rescue CD which does support encrypted filesystems. For this example, I use the Gentoo minimal Live CD, as it has all the necessary kernel and userspace support to create an encrypted filesystem.

First, download the Gentoo minimal Live CD from OSUOSL or another mirror. (Currently the latest Live CD is /releases/x86/2006.1/installcd/install-x86-minimal-2006.1.iso.) Then burn it to a CD. It’s small enough to fit on a business card size CD. You can use another Linux live CD as long as it has a recent kernel and recent LUKS userspace utilities.

I am going to assume that you accepted all the partitioning defaults when you installed Fedora Core, and that your root partition is located at /dev/VolGroup00/LogVol00. If you installed it elsewhere, you’ll have to substitute the correct device. Also, I’ll assume that your second hard drive (or partition) which we’ll use temporarily will be at /dev/sdb1. Substitute your actual partition when running the commands below. Keep in mind that anything on that drive or partition will be destroyed!

The first thing you need to do is boot your (freshly installed?) Fedora Core system. You’ll need to obtain a patched copy of mkinitrd that understands encrypted root filesystems and can prompt you for the password. You can either get the patch yourself from Red Hat’s bugzilla and build RPMs yourself, or you can use the ones I’ve built for my own use. If you’re extremely paranoid, I suggest you build your own, but the instructions on how to integrate patches into and build RPMs are beyond the scope of this article.

Download the mkinitrd RPM and its dependency, libbdevid-python (and nash on FC6). The mkinitrd-devel package is optional. I’ve also provided the source RPM, with patch included, in case you really want to rebuild the packages yourself.

Fedora Core 5:

• libbdevid-python-5.1.15-1.i386.rpm (required)
• mkinitrd-5.1.15-1.i386.rpm (required)
• mkinitrd-devel-5.1.15-1.i386.rpm
• mkinitrd-5.1.15-1.src.rpm (source)

Fedora Core 6: (This is currently BROKEN on Fedora Core 6. Do not proceed until an update has been posted and this notice removed.)

• libbdevid-python-5.1.19-1.i386.rpm (required)
• mkinitrd-5.1.19-1.i386.rpm (required)
• nash-5.1.19-1.i386.rpm (required)
• mkinitrd-devel-5.1.19-1.i386.rpm
• mkinitrd-5.1.19-1.src.rpm (source)

Then install the packages. On Fedora Core 5, you may need to use the --nodeps option with these files as they were built against rawhide (but they work fine).

Fedora Core 5:

[root@fedora ~]# rpm --nodeps --replacefiles --replacepkgs -Uvh mkinitrd-5.1.15-1.i386.rpm libbdevid-python-5.1.15-1.i386.rpm

Fedora Core 6:

[root@fedora ~]# rpm --replacefiles --replacepkgs -Uvh mkinitrd-5.1.19-1.i386.rpm libbdevid-python-5.1.19-1.i386.rpm nash-5.1.19-1.i386.rpm

The next thing you’ll need to do is update everything. Among other things this will pull in the latest kernel, which you’ll need for encrypted filesystem support. The patched mkinitrd will, when the kernel update installs, create an initrd which understands encrypted root filesystems. The patched mkinitrd requires at least kernel version 2.6.17-2174. (2.6.18-2200 is current in FC5 at the time of this writing, and 2.6.18-2798 is current in FC6.)

root@livecd ~ # yum upgrade

Connect your second hard drive to the system, which we’ll use temporarily to encrypt all your files, and then boot from the Gentoo live CD or other live CD. Eventually you’ll get a root shell prompt. The first thing we’ll do is create mount points to mount our partitions:

root@livecd ~ # mkdir -p /mnt/disk1 /mnt/disk2

Next we need to load up the logical volumes:

root@livecd ~ # vgchange -ay
  2 logical volume(s) in volume group “VolGroup00″ now active

Next we’ll create the temporary partition on your second drive. It will be created at /dev/mapper/temp. We’ll also encrypt it using a throw-away key so that the data can’t easily be recovered later. (The /tmp directory is in RAM on the Gentoo live CD.)

root@livecd ~ # dd bs=32 count=1 if=/dev/random of=/tmp/temp-key
root@livecd ~ # cat /tmp/temp-key | cryptsetup luksFormat /dev/sdb1
root@livecd ~ # cryptsetup -d /tmp/temp-key luksOpen /dev/sdb1 temp

Now we’ll mount both the original partition and the temporary partition.

root@livecd ~ # mount /dev/VolGroup00/LogVol00 /mnt/disk1
root@livecd ~ # mke2fs -j /dev/mapper/temp
root@livecd ~ # mount /dev/mapper/temp /mnt/disk2

Then we’ll copy all the files over to the temporary partition, then unmount the original partition.

root@livecd ~ # cp -ax /mnt/disk1/* /mnt/disk2
root@livecd ~ # umount /mnt/disk1

The next step is to securely erase the original parititon which contained the unencrypted files. By default this command will write 25 different known and random patterns to the entire partition, which should leave the data formerly on it unrecoverable. Depending on the size of your drive, this may take several hours. You can add the -v option to see a progress report.

root@livecd ~ # shred /dev/VolGroup00/LogVol00

If you didn’t have any sensitive data on the disk, or you don’t care very much, then you can just write one pass of random data to the drive, which you’ll need to do anyway to help frustrate any future cryptanalysis. If you fail to do this, an attacker could be able to determine what data on your drive is encrypted, and what is garbage, and have an advantage in trying to recover your data.

root@livecd ~ # shred -n 1 /dev/VolGroup00/LogVol00

Finally, it’s time to set up the real encrypted filesystem and move your files back to your hard drive. First, you need to decide whether you want to use a passphrase to encrypt (an intermediate key which will then encrypt) your data, and boot directly from the hard drive, or whether you want to boot from a USB stick which contains your encryption key. I won’t be covering the USB stick method here, as right now it’s much more complex, the code isn’t well tested, and it’s much more inconvenient to use and maintain. As the code develops, I may post an update in the future.

Whether using a passphrase or a USB stick containing the key is the best method depends on your particular situation and the threats you are likely to face. For most people, the passphrase should be quite sufficient (provided it’s long enough). People who choose the USB stick method are those rare people who face torture or death if their data is compromised, and where simply losing the USB stick is sufficient to protect the data; since you don’t know the key, it can’t be rubber-hosed out of you. At the same time, though, you risk being captured with the USB stick still in your possession, which means all your efforts are for nothing. So there’s no one best solution for everyone.

The good news is you can start out with a passphrase now, and switch to a key on a USB stick later (when the code is better tested), without having to copy all your files around again.

So let’s encrypt your filesystem. Choose a long passphrase that’s easy for you to remember, but very difficult for anyone else to guess.

root@livecd ~ # cryptsetup -y -d aes-cbc-essiv:sha256 luksFormat /dev/VolGroup00/LogVol00
Enter LUKS passphrase:
Verify passphrase:

Now we’ll map the encrypted device at /dev/mapper/root, create the filesystem and then mount it.

root@livecd ~ # cryptsetup luksOpen /dev/VolGroup00/LogVol00 root
Enter LUKS passphrase:
Verify passphrase:
root@livecd ~ # mke2fs -j /dev/mapper/root
root@livecd ~ # mount /dev/mapper/root /mnt/disk1

Then we’ll copy all the files back from the temporary filesystem.

root@livecd ~ # cp -ax /mnt/disk2/* /mnt/disk1

One last thing. The Gentoo live CD doesn’t have support for SELinux, so if you use SELinux, (it’s enabled in the default Fedora Core installation) then everything on the new filesystem needs to be relabeled. So we’ll ask for that to happen on the next reboot.

root@livecd ~ # touch /mnt/disk1/.autorelabel

That just about covers it. Reboot the system, take out the live CD, and boot into your freshly encrypted new Fedora Core system! You’ll almost immediately be prompted to enter your passphrase. You have to get it right the first time; if you don’t, then you must hard reset the machine before trying again.

You can now erase the temporary hard drive you used for transferring your files around, if you like. The encryption key for it was random data which resided only in memory, and by this point will be long gone. Just to be safe, you can overwrite the disk partition you used again with some random data:

[root@fedora ~]# shred -n 1 /dev/sdb1

That should cover it. This thing has gotten just about as long as I’m comfortable making a post, so for the USB stick instructions, you’ll have to wait for part 3 (you can read the bugzilla for hints, but the instructions there are for PowerPC platforms). I also plan a quick tutorial on encrypting non-root partitions, in case you’re one who made your disks into multiple partitions and put different parts of your system on each partition. So I’ll wrap both of those into the update in probably a week or two.

If you find anything confusing, or catch any technical errors, please let me know and I’ll get them cleared up or corrected as soon as possible. Thanks!