Recently in hacks Category

Introduction

About five months ago, I wrote about how to convert an existing Linux install from using regular partitioning to encrypted volumes (in particular, an encrypted /home with an unencrypted /). That sort of setup is relatively simple, once you have all the partitioning done. There is no need for any special early userland stuff (an initramfs image). However, that approach only provides a relatively minimal level of security for your data -- someone could still root your system.

For those who are a little more paranoid (especially in light of some recent news), the next level of security for your data is to encrypt everything except your /boot partition.

Going to this level, you're going to be repartitioning pretty much your entire hard disk, so you might be best off just backing up everything (you should do this in any case), and reinstalling your system.

Some recent Linux installers make this sort of setup relatively pain-free. For example, Ubuntu 8.04's Alternative install disk gives the option of setting up an encrypted LVM volume to install the system on during its guided partitioning wizard. This is a rather easy way have your laptop's data securely encrypted quickly. However, with this setup, I wasn't able to get suspend-to-disk support to function properly (though I'm sure it could be done with a little extra effort, I don't know if most Ubuntu users would be willing to do so).

However, this guide is focused on the crowd of people who use distros that do not make this easy. For myself, I'm installing Exherbo during this guide, but the instructions should be almost exactly the same for Gentoo, or most any other distro.

Partitioning Overview

For this first step, you will need to create two standard disk partitions. The first should be only 32M or so in size -- this will be our /boot partition, and should probably be ext2. The second will be the rest of the space you wish to devote to this Linux install (in my case, 10G).

The final layout of everything is going to be like this:


/dev/hda1 - /boot
/dev/hda2 - dm-crypt encrypted volume, containing one lvm2
  physical volume

/dev/mapper/hda2_crypt - what we get when we run cryptsetup luksOpen
  on hda2, contains one lvm physical volume, containing the volume
  group "vg"

/dev/mapper/vg-swap - our swap partition
/dev/mapper/vg-root - our root partition

With this layout, all our data that can be encrypted / lvm-ized is. And we only need to enter our disk decryption key once to get to all of it.

Next Time...

In my next few posts, I'll go into more details about how to set this partition scheme up, how to configure your kernel, and how to create the necessary initramfs image to boot from an encrypted @/@ partition.

Encrypting your /home

| | Comments (2) | TrackBacks (0)

I was inspired by a post on the Command Line Warriors blog to encrypt my /home directory. Unfortunately, the directions given in that post don't quite work. Here is the process I followed to set everything up.

We're setting up a basic LUKS volume encrypted with AES with a 256-bit key. This means we make a special "filesystem" on the disk partition which encrypts our real filesystem on disk, and makes it available unencrypted via the device-mapper interface (/dev/mapper/).

First, you need to have a partition available for your /home directory. In my case, I decided to nuke my Windows install, but most people will probably need to use parted to resize some existing partitions. If you're resizing your root ("/") partition, you'll need to run it from a LiveCD. For the partition, I chose the "Linux" type, but I'm not sure that really matters.

Once you've allocated the partition, you'll need to create the LUKS partition. You do this with the cryptsetup command. But, before you can use this, you'll need to make sure you've compiled these settings into your kernel: CONFIG_DM_CRYPT, CONFIG_CRYPTO_CBC, CONFIG_CRYPTO_SHA256, and CONFIG_CRYPTO_AES.

After configuring your kernel and you've rebooting, if need be, you'll need to install sys-fs/cryptsetup. Don't install sys-fs/cryptsetup-luks... it's old. The newest (>1.0) versions of cryptsetup are based on the -luks version, and are what you should be using.

Now, use cryptsetup to format the luks partition:


  cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/hda4

Substitute /dev/hda4 with whatever partition you created earlier. It will ask you to enter a password. Use a strong one, and don't just write it on a piece of paper by your computer, or you've defeated the whole point of this.

Now, we need to open the partition so we can create our encrypted data partition. We do this with the following:


  cryptsetup luksOpen /dev/hda4 crypt-home

This will make /dev/mapper/crypt-home, which is the device you use to mount your /home. Currently that partition is unformatted, so use your mkfs of choice to format it.


  mke2fs -j /dev/mapper/crypt-home

Next, make a temporary place to mount this so you can copy over your data, and mount it.


  mkdir /mnt/crypt-home
  mount /dev/mapper/crypt-home /mnt/crypt-home

And then, copy all your data from your current /home to the new one:


  rsync -tarv /home/* /mnt/crypt-home

Now would also be a good time to back up your important data to some other location.

Before we continue, we should configure the system to mount our new /home at boot. This requires editing /etc/fstab:


  # /etc/fstab
  # ... your other stuff ...
  /dev/mapper/crypt-home /home ext3 noatime 0 2

and /etc/conf.d/dmcrypt:


  # /etc/conf.d/dmcrypt
  # This file has all sorts of comments in it already
  # just uncomment the following:

  ## /home with passphrase
  target=crypt-home
  source='/dev/hda4'

Now all that is left is to remove the unencrypted copy of /home. First, you should go through and rm -rf anything that doesn't contain sensitive information, like open source project code, your mp3s, etc.

The last step is to use the shred command to securely delete all the remaining files. Shred works by overwriting a file many times with different patterns to make recovering them extremely difficult. Use the following commands to securely delete all the files in home, and then remove all the empty directories:


  find -H /home/*/ -type f -exec shred -u -v {} \;
  rm -rf /home/*/

Now, reboot and if everything went well, you should be prompted for your password, and then everything should just work as it did before.

So, been a while, but here's something I just threw together. It's still a little rough around the edges, but it seems to be more robust than tpb for my system, at least, and it doesn't require me to make /dev/nvram available.

It uses /sys/class/backlight/thinkpad_screen/actual_brightness (from the thinkpad_acpi module in the 2.6.22 kernel) to figure out the screen brightness, and /proc/acpi/ibm/volume to figure out the volume and mute states, also provided by the thinkpad_acpi module (I'll switch to using sysfs for this when it becomes available).

It also requires the ruby-xosd package, which you can get from my overlay: svn://svn.pioto.org/pioto-overlay

For lazy paludis users, just add this to /etc/paludis/repositories/pioto-overlay.conf:

format = ebuild
location = /var/paludis/repositories/pioto-overlay
sync = svn://svn.pioto.org/pioto-overlay
master_repository = gentoo
names_cache = /var/cache/paludis/names
write_cache = /var/cache/paludis/metadata

You can get the current version of this script from subversion at: http://svn.pioto.org/rbtpb/trunk/

Finally found a few decent ways to get around that obnoxious behavior of popping up the same dialog every 10 minutes, even after I said “No” over on the Coding Horror blog.

The quick `n easy way is to run net stop wuauserv. This will stop the reminders, as well as auto updates, until you reboot.

To make it less obnoxious in a few ways in the future, I found the “No auto-restart for scheduled Automatic Updates installations” options to fit the bill pretty well. It prevents automated reboots only if someone is logged in. So, my unattended workstation at work will reboot after auto updates, but my desktop at home will wait until I tell it to.

I found another nice little read on the subject on the Tim Rains’ MSDN blog.