The wikis are now using the new authentication system.
If you did not migrate your account yet, visit

SDB:Encrypted root file system

Jump to: navigation, search
This procedure was tested on Leap 15.0, 15.1, 15.2, 15.3 and 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 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:

It is also possible to create encrypted partitions on a running system through the 'Partitioner' program in YAST. However, encrypting an existing partition destroys all data on it, and requires re-sizing and restructuring of existing partitions.

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 so that you only type the decryption passphrase in the bootloader.

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 an empty key file.
    sudo touch /.root.key
    Only root should be able to read this file.
    sudo chmod 600 /.root.key
  2. Generate the key.
    sudo dd if=/dev/urandom of=/.root.key bs=1024 count=1
  3. Add the key file as a valid way to decrypt your root partition.
    sudo cryptsetup luksAddKey /dev/sda1 /.root.key  # replace /dev/sda1 with the root partition (`sudo fdisk -l` to see partitions)
  4. Edit /etc/crypttab, find the row that pertains to the root partition by UUID 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:
    echo -e 'install_items+=" /.root.key "' | sudo tee --append /etc/dracut.conf.d/99-root-key.conf > /dev/null
    (Note the spaces before and after the doublequote characters.)
  6. Make /boot accessible for root only. This prevents non-root users to read the initrd and extract the key file. To ensure that new permissions are not overwritten at a later timepoint, add the following line to /etc/permissions.local:
    /boot/ root:root 700
    Set permissions.
    sudo chkstat --system --set
  7. Rebuild the initrd.
    sudo mkinitrd

If you have other encrypted partitions (e.g. /home, swap, etc), you can create additional keys to mount them without entering a passphrase. This works exactly as described above in steps 1-4, except that you don't need to add the key for those partitions to the initrd. However, step 7 is still required for the changes to be applied.

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.