Data and Filesystem Encryption

So far, we've been concerned mainly with securing access to data, and not the actual data itself. At a basic level, file permissions and ACLs enforced by the Linux kernel can protect your files from the prying eyes of other nonroot users on your system. But what if someone compromises your login password or gains root access through one of the security exploits, or simply steals a backup tape or a hard drive or even the whole server?

To guard against these possibilities, you can employ encryption to scramble your data so that a secret password or key is required to unscramble and make it intelligible again. Thus, merely gaining the ability to read your files is not enough; an intruder must also have your secret password to make any sense out of the data. There are two ways in which you can protect your data: either selectively encrypt files that need securing or encrypt the whole filesystem on which the data resides.

Most Linux distributions include an excellent encryption software program: the Gnu Privacy Guard, also known as GnuPG or GPG. If you are familiar with Pretty Good Privacy (PGP), you'll find GnuPG quite similar but far more configurable. The main program in the GnuPG package is called gpg and has more than 100 possible command-line flags.

NOTE

If you want to install GnuPG on your SLES server, it is easiest to use YaST and search for packages with gpg in their descriptions. Visit http://www.gnupg.org for the latest version and online documentation.

Based on OpenPGP (RFC 2440), GnuPG supports two types of encryption: symmetric (or secret-key) and asymmetric (or public-key). In symmetric encryption, the same key, or password, is used for encrypting and decrypting the data. Public-key encryption, on the other hand, uses two related keys (a key pair) known as the public and private (secret) keys. They are related mathematically in that data encrypted with the public key can only be decrypted with the private one, but it is not computationally feasible to discover the private key based on the public key. Therefore, the general usage of asymmetric encryption is that you make known your public key to anyone who is interested in sending you secured information, while you keep your private key to yourself. The sender sends you the data encrypted using your public key, and you decrypt it using your private key. Although other people may have your public key, it cannot be used to decrypt the message.

CAUTION

Before using a public key to encrypt sensitive information to send to someone, make sure that the key actually belongs to that person. GnuPG allows a key to be signed, indicating that the signer vouches for the key. Signing works in much the same way as the SSL certificate sent by a web server to your browser where a trusted root certificate is used to verify the authenticity of the SSL certificate.

You can also make your public key available to others via a key server (which acts as a trusted third party). You can submit your public key to one of the many key servers available on the Internet. Two such servers are www.keyserver.net and pgp.mit.edu. Remember that even though you may have retrieved someone's public key from a well-known key server, you should check the key fingerprint with the owner before totally trusting it.

Symmetric encryption is much simpler to use because you only need to use the same key for encrypting and decrypting. Public-key encryption requires some setup, at the very least generating a key pair, but it is more flexible. For instance, it allows others to send you encrypted data without having to first agree on a shared secret key. Therefore, symmetric encryption is often used for safeguarding your own data that is generally not shared with others, and asymmetric encryption is often used when sensitive data is to be transmitted between different parties.

It is beyond the scope of this chapter to go into the details of GnuPG, such as key and trust management and key servers. We refer you to the documentation. The following examples serve to illustrate how you can use it to protect your data files:

• To encrypt a file with a (symmetric) secret key using GnuPG, use the following:

   Athena:/home/admin # gpg -c filename 

  
  

  You will be prompted for the key, and the encrypted file will have a .gpg suffixfor example, filename.gpg.

• To encrypt a file using the recipient's public key, use this command:

   Athena:/home/admin # gpg -e -r recipient_key_id filename 

  
  

  Note that you need to have already added the recipient's public key to your "key ring" (key database) before you can use it. You can encrypt a file for more than one recipient by including additional -r key_id switches to the command.

  TIP

  You should include yourself in the recipient list by specifying your own public key at encryption time (-r your_key_id). Otherwise, you would not be able to decrypt the file yourself.

  
  

• To decrypt an encrypted file, use this command:

   Athena:/home/admin # gpg filename.pgp 

  
  

  You will be prompted for the password if the file was symmetrically encrypted or the private key if it was asymmetrically encrypted. The resulting decrypted file will be named filename. If you specify the -d switch, the output is sent to stdout, which you can redirect to a file or use as pipe input to another program.

• To use GnuPG's asymmetric encryption to encrypt all of Tasha's accounting-related files on the server so only she and you can decrypt them, use the following command:

   Athena:/home/admin # find /accounting -user tasha -type f \ -exec gpg -e -r tasha_key_id -r your_key_id {} \; 

  
  

Because of the number of option flags available, you can choose from a wide variety of programs that either use or support GnuPG encryption to make your life easier when using GnuPG. Some GUIs (such as KGpg for KDE desktops and Seahorse for GNOME) simplify your key management tasks to just a few mouse clicks. There are also many Mail User Agents (MUAs) that let you encrypt and sign your email messages seamlessly. You can find a comprehensive list of these and other utilities at http://www.gnupg.org/(en)/related_software/frontends.html.

If you have many files to encrypt or have files transparently encrypted without user intervention, it may be easier to set up an encrypted filesystem. If you have any removable drives on your server, such as hot-swappable hard drives or USB devices, filesystems on them should be encrypted to guard against theft. SLES 9 includes the capability of an encrypted filesystem out of the box.

You can set up encrypted partitions either during initial server installation or later. You can create an encrypted virtual filesystem at any time after the server has been installed because it fits nicely in an existing partition layout. To encrypt an entire partition, you need to dedicate a partition for encryption in the partition layout. The standard partitioning proposal as suggested by YaST does not, by default, include an encrypted partition. You need to add it manually in the partitioning dialog box.

VIRTUAL FILESYSTEM

Linux allows you to take an ordinary disk file; format it as an ext2, ext3, or Reiser filesystem; and then mount it, just like a physical drivethrough the help of loopback devices. (A loopback device is a special device that allows you to mount a normal file as if it were a physical device.) After it is mounted, you can then read and write files to this newly mounted "device" as if it were a filesystem residing on a real hard drive. Because it is just a file, you can also copy the complete filesystem to another computer and use it there.

During the server installation phase, the YaST expert dialog box for partitioning offers the options necessary for creating an encrypted partition. Follow the same steps as you would to create a typical partition, but ensure you select the Encrypt File System check box before clicking Next. You will be asked for a password required to mount the filesystem; the operating system will prompt you for this password at server boot. If no password was provided or a wrong password was entered, the encrypted filesystem will not be mounted. If the encrypted filesystem should be mounted only when necessary, check Do Not Mount During Booting in the Fstab Options dialog box.

WARNING

If you forget the password, you cannot mount the filesystem and access its data.

If you want to convert an existing filesystem into an encrypted filesystem, follow the same procedure as just described, but select the desired partition and click Edit instead of Create. Note that this conversion will destroy all existing data on the partition!

For an existing system that has available free disk space, instead of converting an existing partition to be encrypted, it may be best to create a virtual encrypted filesystem. You accomplish this from the same YaST disk partitioning dialog box. Instead of selecting Create or Edit, select Crypt File. In the Create New Loop Device Setup dialog box (see Figure 6.3), enter the path to the file to create along with its intended size. Modify the proposed settings for formatting and the file system type as necessary. Then specify the mount point and decide whether the encrypted filesystem should be mounted during boot.

Figure 6.3. Creating a virtual encrypted filesystem.

If you want a commercially supported alternative, BestCrypt for Linux (http://www.jetico.com) is an option.

NOTE

A number of free encrypted filesystem implementations are also available:

• EncFS (Encrypted Filesystem module for Linux; http://arg0.net/users/vgough/encfs.html)

• CFS (Cryptographic File System; http://www.crypto.com/software)

• TCFS (Transparent Cryptographic File System; http://www.tcfs.it)

Be aware that not all of them have been tested with the 2.6 Linux kernel, which SLES 9 uses.

You should consider the following potential drawbacks before deploying filesystem encryption on your servers:

• When an encrypted filesystem is mounted, you must supply the passphrase that was used to create the filesystem. Therefore, if you set up any encrypted filesystem to automount at boot time, someone needs to be at the server console to enter the passphrase (which makes remote management challenging).

• You can set the encrypted filesystem not to automount at server boot but mount it at a later time. However, this means the users will not have access to this filesystem until it is mounted.

• When the encrypted filesystem is mounted, anyone with the proper permissions can read and write data to the disk at any time transparently. It's only when the disk is unmounted and "stolen" that the data would be useless.

• Depending on the implementation, the tape backups may be in unencrypted form.

• If the passphrase is forgotten, everything is lost or inaccessible.

Therefore, before you implement, invest some time in up-front planning work.