SDB:Encrypted root file system

Jump to: navigation, search
Icon-checked.png This procedure was tested on Version 11.4
Icon-checked.png This procedure was tested on Version Tumbleweed


This article gives a description how to set up a system encrypted as a whole not only with encrypted personal or user data or an encrypted partition for /home.

Introduction and Motivation

Most laptop users do not begin to think about the problems associated with laptop theft until after the first theft occurs. If the laptop happened to contain the source code for a new product, or company confidential documents, or the notes for an newspaper article on political corruption, or maybe just a private love letter, then there is a potential for catastrophe if the data falls into the wrong hands.

To counter the potentially damaging affects of laptop theft, one can either choose not to use a laptop, use hardware encryption devices, or use software encryption to protect the data. The latter approach is particularly attractive because a software solution is more flexible than a hardware approach and with a modern CPU, most users will not notice the performance penalty associated with on-the-fly software encryption/decryption.

Why encrypt the root file system?

At first glance, one is inclined to encrypt only the most sensitive files, or perhaps the entire user file system (/home) containing the sensitive information. If one is not encrypting the root file system, then this is a simple enough exercise which is supported by the SUSE installation procedure, as well as other software, some of which even runs in user space. However, the problem with such an approach is that the contents of an encrypted file tend to leak out of the encrypted area into other areas, e.g. swap, /tmp, and /var. Furthermore, editors or other programs used for working with the data may create swap files in other locations as well. Finally, metadata related to the file, such as its size, permissions, access time etc. of modern journaling filesystems possibly being stored on separate paritions only compound such problems. In general, then, it is not easy to fully prevent the leakage of information from the user's file system into the root file system.

To understand how big the problem can be, suppose a company has installed a web server on its intranet for the purpose of distributing company confidential information. If an employee is viewing a doc file from this web server with Firefox using the OpenOffice.org plugin, then the complete file is stored in /tmp and remains there until it is erased. Hence, while there maybe only bits and pieces of a sensitive document in swap, the entire document could be available in /tmp.

For this reason, the only appropriate course of action is to encrypt the entire root file system, along with the file system containing the sensitive data.

Installing openSUSE with encrypted root file system

Encrypting the root file system, as well as the home, tmp and other partitions is now fully supported in the Opensuse graphical installer. On already installed systems it can be done through the 'Partitioner' program in YAST.

Instructions can be found under the heading 'Local Security' in the 'Security Guide', which is part of the official Opensuse manuals.

Opensuse Official Documentation

'Encrypting Partitions and Files' chapter in the openSUSE Security Guide

Avoiding to type the passphrase twice

A disadvantage of encrypting the root partition is that you'll have to provide the decryption passphrase twice - once in the bootloader (Grub), and then again when your system actually boots. You can avoid this by adding a key file to your initrd.

Warning: Do this only if you have an encrypted root partition that includes /boot (no separate /boot partition)!

The key added to the initrd can be used to decrypt your root partition, therefore having the initrd on an unencrypted /boot partition would defeat encrypting your root partition.

The steps below describe how to set up a key file. Please execute the commands and edit the files listed below as root.

  1. Create a key file.
    dd if=/dev/urandom of=/.root.key bs=1024 count=1
  2. Make sure the key file can only be read by root.
    chmod 600 /.root.key
  3. Add the key file as a valid way to decrypt your root partition.
    cryptsetup luksAddKey /dev/sda1 /.root.key  # replace /dev/sda1 with the correct partition
  4. Edit /etc/crypttab and add the key file in the third column.
    cr_sda1 UUID=... /.root.key
    (Again, the partition name is just an example.)
  5. Configure dracut to add the key file to the initrd. To do this, create a file /etc/dracut.conf.d/99-root-key.conf with the following content:
    install_items+=" /.root.key "
    (Note the spaces before and after the doublequote characters.)
  6. Make /boot accessible for root only.
    chmod -R g-rwx,o-rwx /boot
    This prevents non-root users to read the initrd and extract the key file.
  7. Rebuild the initrd.
    mkinitrd

If you have other encrypted partitions (for example /home), you can create additional keys to mount them without entering a passphrase. This works exactly as described above, except that you don't need to add the key for those partitions to the initrd.

Passphrase locale

The current openSUSE setup does not support to set the locale for the grub2 early stage. This causes that the passphrase in grub2 is using a US keyboard layout.