This wiki was updated to MediaWiki 1.37. If you notice any issues, please report them to admin[at]

SDB:Encrypted root file system

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

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
    To find the name of the device on your system, use sudo lsblk. Find in the tree an entry listed as type crypt. Right above it you should see an entry of type part. That is your partition name. It might have a name like sda2 or nvme0n1p2.
  4. Edit /etc/crypttab, find the row that pertains to the root partition by UUID and add the key file in the third column where it might already say none.
    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 dracut -f

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.

Avoiding to type the passphrase twice in MicroOS

This is what you need to do to avoid typing password twice in openSUSE MicroOS:

  1. Open the transactional-update shell.
    sudo transactional-update shell
  2. Follow the steps described in the "Avoiding to type the passphrase twice in Leap and Tumbleweed" section in the same way.
  3. After following the steps of the previous section, close the transactional-update shell as usual.

Now the system should ask the password once in the next system boot.

Additional steps when using hibernation with encrypted swap partition

If you want to hibernate your system and the swap partition is also encrypted, in such case, repeat step 5 using the key for the swap partition. Next you need to tell dracut to include the encrypted swap partition so it gets decrypted upon reboot.

To find the UUID of the encrypted partition that contains the swap partition use sudo lsblk -o +UUID. Find in the tree an entry listed as type crypt [SWAP]. Right above it you should see an entry of type part. That is your encrypted partition containing the swap partition. It might have a name like sda2 or nvme0n1p2. The UUID looks something like abc4eef4-f9ac-7788-abc0-cda56baabf08 and is on the right side at the same line.

Configure dracut to add the encrypted partition containing the swap partition to the initrd using its UUID:

echo -e 'add_device+=" UUID=... "' | sudo tee --append /etc/dracut.conf.d/99-swap-partition.conf > /dev/null

(Note the spaces before and after the doublequote characters.)

Now repeat step 7 from above to rebuild the initrd.

Don't forget to add the line resume=UUID=.... (using the UUID of the encrypted partition containing swap) to the bootloader kernel-paramter using Yast.

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.