SDB:Encrypted root file system
tagline: From openSUSE
|This procedure was tested on Version 11.4|
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.
Information for current Opensuse Versions (Opensuse 11.2 and newer)
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.
Information for deprecated Opensuse Versions (Opensuse 11.1 and older)
Consider upgrading to Opensuse 11.2 or newer as the procedure to do this in old Opensuse versions is difficult. This procedure is described in the page SDB:Encrypted_root_file_system_(deprecated)