If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
SDB:Encrypted root file system
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,
/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
server with Firefox using the OpenOffice.org plugin, then the complete file is
/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
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.
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.
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.
- Create an empty key file.
sudo touch /.root.keyOnly root should be able to read this file.
sudo chmod 600 /.root.key
- Generate the key.
sudo dd if=/dev/urandom of=/.root.key bs=1024 count=1
- 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)
- 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.)
- 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.)
- 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 700Set permissions.
sudo chkstat --system --set
- Rebuild the initrd.
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.
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.