Securing laptops with ecryptfs, cryptsetup, and tmpfs

One of the awesome features of the last several Ubuntu releases is support for ecryptfs, an encrypted filesystem. At Talia we depend heavily on GPG, OTR, SSH keys and other forms of encryption and secure identification. Loss of those keys and other confidential data to laptop theft, corporate espionage, or the US Customs Service is a big concern for us. This week I secured my laptop, as a prototype of our new corporate laptop setup. Here is how I did it.

Nothing in this process is specific to KDE, so Ubuntu or Xubuntu users can use this as well. Steps:

  1. Choose a strong password
  2. Create an encrypted ~/Private directory
  3. Copy home directory files into ~/Private
  4. Move ~/Private to $HOME
  5. Encrypt swap
  6. Make /tmp a tmpfs

Caveat emptor: If you encrypt your home directory, then later forget your password and fail to write down the mount passphrase, you are screwed. There is no practical chance that you will recover your files. As always, make a backup.

Step 1: Choose a strong password

If you aren’t already doing this, you’re not likely to use this guide. Security is a mindset, not a tool. Get used to keeping strong passwords in your head. Ubuntu makes using encryption really easy, but it is only as effective as the strength of the password you choose.

My recommendation is to use pwgen with -B or even -By:

pwgen -By

Ohz:ah7s aiT7gex% AhNae)Z3 Ohph*i9e va9eZuo[ Mei7ieZ~ Ohb7Za]o Piek+ai3
fa!m3Sho ua~ch7Wa tom?oh9U do{i4Aep tuF4oof} Na#a4eiH epe\G3oh aR3ahp^i
...
Aip$aim9 Eph%a3pu gae7aY`a Ie^cah4t sha+uY3v ove3aeZ= Wie4yei| Oc\aeb9e

The -B option tends to generate passwords that are balanced between hands and at least partly pronouncible, so this isn’t as hard as you think. If you do use -y (special characters like +), consider the keyboards you might have to use. If you use both British and American keyboards, don’t use £, @, “, `, #, ~, \, or |, as all of these are in different locations.

Pick one and and make a mnemonic to help you remember it. Write it on a piece of paper, put it in your wallet, and burn it once you memorise it. Write it on your belly with a sharpie; whatever it takes. Change your password now:

passwd

Your password will later become the passphrase that protects the encryption keys to your home directory. ecryptfs includes excellent PAM support, so if you change your password later it will update the key too.

Step 2: Create an encrypted ~/Private directory

Since I upgraded from an earlier install without an encrypted home or ~/Private directory, I had to create one. If you are about to install 9.10 from a CD, the installer has an option to encrypt your home directory. Just use that. Or create a new user:

adduser --encrypt-home username

If you’ve already got an encrypted home, congratulations! The hardest part is done. Skip to step 5.

If not, let’s get started. Linux Mag’s Dustin Kirkland has written an excellent guide to this process. Much of my process is based on his, but I include a few corrections. For most of this you can remain logged in to your Desktop, but the process is simpler from the Linux console. The initial copy process will make you want to get up and do something else while it finishes anyway.

Logout from the Desktop, which should return you to the login screen. If your login screen is configured to log you in automatically, cancel it. Then press Ctrl+Alt+F1 to go to the first Linux virtual console.

Login at the prompt, and create an encrypted $HOME/Private directory:

ecryptfs-setup-private

Enter your login passphrase:
Enter your mount passphrase [leave blank to generate one]:

At the first prompt enter your user password. At the second, press Enter. Now record the mount passphrase which was just generated:

ecryptfs-unwrap-passphrase $HOME/.ecryptfs/wrapped-passphrase

Print it out and put it with your birth certificate in your fire-proof document safe. You do have one, right? If something goes wrong you will need this later.

Log out, and log in again.

Step 3: Copy home directory files into ~/Private

Make sure you have at least 50% free on /home, or this may fail.

rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs $HOME/ $HOME/Private/

If you don’t have 50% free, first move some files from $HOME to $HOME/Private, and rsync the rest.

cd
mv -v Videos Music Pictures DirectoryOfBigFiles $HOME/Private/
rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs $HOME/ $HOME/Private/

This will take a long time to complete. Every file is being encrypted as it is copied or moved. If you have a lot of files and an under-powered CPU (such as on a netbook), it will take even longer. I moved 178 GB of data on my Dell Vostro 1500 (Intel Core2 Duo 2 GHz, 4GB RAM) in about 5 hours. Get a coffee, walk the plants, shave the cat, come back later.

When done, logout to sync any remaining changes to disk.

Step 4: Move ~/Private to $HOME

Now we need to do some things with sudo. Still on console, login again. Unmount $HOME/Private:

ecryptfs-umount-private
cd /
sudo mkdir -p /home/.ecryptfs/$USER
sudo chown $USER:$USER /home/.ecryptfs/$USER
sudo mv $HOME/.ecryptfs /home/.ecryptfs/$USER/

Create a new home and populate it with the ecryptfs files:

sudo mkdir -p -m 700 /home/$USER.new
sudo chown $USER:$USER /home/$USER.new
sudo mv $HOME/.Private /home/.ecryptfs/$USER/
sudo ln -s /home/.ecryptfs/$USER/.ecryptfs /home/$USER.new/.ecryptfs
sudo ln -s /home/.ecryptfs/$USER/.Private /home/$USER.new/.Private
sudo ln -s /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt /home/$USER.new/README.txt

Switch to the new home, tell ecryptfs that we’ll mount it at login, and make it read-only (until it is mounted):

sudo mv $HOME $HOME.old
sudo mv $HOME.new $HOME
echo $HOME > $HOME/.ecryptfs/Private.mnt
sudo chmod 500 $HOME

Now for the moment of truth. Still on console, logout, and login again. Your home directory should mount:

mount | grep ecryptfs

/home/username/.Private on /home/username type ecryptfs (ecryptfs_sig=9cec4d81c9bcb6e0,ecryptfs_fnek_sig=c735e6facb299611,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

Create some convenient links:

ln -s /home/.ecryptfs/$USER/.ecryptfs $HOME/.ecryptfs
ln -s /home/.ecryptfs/$USER/.Private $HOME/.Private

Once you verify that all your user data is there, securely wipe any files that have important data, and then remove the old home.

cd $HOME.old
find .kde .gnupg .ssh PathsToDirectoriesOfImportantFiles -print -exec shred -u {} \;
rm -rf $HOME.old

Step 5: Encrypt swap

Your home directory isn’t the only place your private data may be written to disk. When your computer doesn’t have enough RAM for everything it wants to have open, it swaps. This means some RAM is written to disk to be read back later. Thus, swap can contain anything you have ever have open. Swap does not need normally to survive reboots *, so we’ll encrypt this with a random key every time we boot up.

* The one exception to this is hibernate mode (suspend to disk). If you want to use hibernate, don’t encrypt swap, or use a (less secure) static key. Encrypting swap has no impact on sleep mode (suspend to RAM). I never use hibernate.

Thankfully, this is a very easy process with Ubuntu. Despite the misleading name, this uses cryptsetup, not ecryptfs:

sudo apt-get install cryptsetup
sudo ecryptfs-setup-swap

Step 6: Make /tmp a tmpfs

The last place your private data is commonly written is the temp directory, /tmp. The contents of this directory don’t need to survive reboot either, and are commonly cleared at bootup. It is possible to encrypt it using cryptsetup just as with swap, but we don’t need to. Instead we’ll make this a tmpfs. This means /tmp will be an auto-resizing virtual RAM disk. By default it is allowed to grow to up to 50% of RAM.

Don’t worry about this consuming your RAM. If the contents of RAM is swapped to disk, static content like /tmp will be the first to go. And it isn’t much data anyway; my /tmp rarely grows beyond 200 MB. Plus, using a tmpfs will save power when in battery mode.

Add one line to your /etc/fstab:

echo "tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0" >> /etc/fstab

If you are logged in to the desktop, log out completely. Then login on console one last time, and run:

sudo rm -rf /tmp/*
reboot

That’s it! You are now running a cryptographically secure laptop, protected against all but the rubber-hose attack.

Tags: , , ,

  1. Daryl’s avatar

    Practical advantages of this over using, say FileVault on the Mac ? (still loves the Ubuntu but use it on the servers… though feel bad I use OSX all the time… =] ).

    Reply

  2. tyler’s avatar

    My only experience with FileVault is reading the relevant wikipedia page, so I can only speculate. From what I read the feature is comparable, but ecryptfs can also be used to encrypt only specific directories. For instance, it is common now to have a ~/Private for this purpose, which is what the ecryptfs-setup-private command does if you just stop there.

    The biggest advantage I can see is that ecryptfs is open source and FileVault is not. Lack of peer review is very bad for cryptographic security.

    Reply

  3. breakpoint’s avatar

    Fedora has allowed install-time filesystem encryption for some time. Additionally, it’s possible do a manual LVM setup that creates a LUKS encrypted LVM partition which in turn has (secondarily encrypted with another key) LUKS encrypted logical volumes. Whether or not this is actually advantageous vs. just using encryption at only one of those layers depends on your situation– the only use I’ve really thought of is allowing somebody to at least get the system to boot using a lower security password but ensure that sensitive systems and data can’t be started or accessed– but it is interesting to note that the performance hit from two layers of crypto was not nearly what I would have expected (admittedly, though, this was running on a stripe set).

    From a consultant’s point of view, the weak point of practically any corporate network is the fact that they’re going to want the keys, they’re going to want to test them, and they’re going to scream bloody murder the first time you try to really lock things down. I’ve been able to get people to choke down restricted access MUCH easier than password hygiene.

    I do, however, make people sign things when they reject my advice these days. My contracts almost always include a clause releasing me from liability for any security incident on a system or network not secured to generally accepted standards and practices (i.e., you use strong passwords, sensitive data is encrypted, physical access to machines is restricted to those with a need to service them, etc.).

    Sounds like your firm has had to react to a few… incidents. Hope none of them were major.

    Reply

  4. tyler’s avatar

    breakpoint,

    The advantage of using filesystem-based encryption versus volume-based is that different users can have different keys, all on the same filesystem. Some information leakage occurs this way: the number of files, approximate sizes, and the size and depth of the directory hierarchy, but I’m not losing any sleep over that. This won’t protect against access to a running system – it’s already mounted and readable to the OS – but it will do a lot for hardware loss.

    We backup our keys, yes, and demand access to and control over company hardware used by employees. I assure you that my key escrow scheme is more secure than most users’ habits. :)

    Reply

  5. Chuck’s avatar

    Thanks for the nice guide :)
    For some time I had an encrypted LVM with /home, /var, /tmp and swap — but dealing with LUKS and cryptsetup was always a bit of a hassle…
    I wonder if (for professionals) /var needs to be encrypted too — but I guess for my private use an encrypted var would be overdone ;)

    Reply

  6. tyler’s avatar

    Chuck,

    It may be wise to encrypt at least /var/tmp/ or link that into /tmp. However, most of what you’ll find there are things like KDE thumbnails and favicons from web pages Konqueror visits. It’s not a major security leak, but it is annoying. Worse, the data here is expected to persist, so linking it into /tmp is not the best practice.

    I wouldn’t bother encrypting /var. If you have a server with data there that matters, you might as well encrypt the whole disk.

    Reply

  7. Heizverteiler’s avatar

    What’s up to all, because I am actually keen of reading this webpage’s post to be updated on a
    regular basis. It contains fastidious material.

    Reply

Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.