Blueprints. Protecting your data at rest with Red Hat Enterprise Linux on System x

Transcription

1 Blueprints Protecting your data at rest with Red Hat Enterprise Linux on System x

2

3 Blueprints Protecting your data at rest with Red Hat Enterprise Linux on System x

4 Note Before using this information and the product it supports, read the information in Notices on page 41. Second Edition (December 2008) Copyright IBM Corporation US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Chapter 1. Scope, requirements, and support Chapter 2. Before you encrypt Chapter 3. Selecting partitions to encrypt Chapter 4. Encrypting partitions using dm-crypt Chapter 5. Encrypting data partitions.. 9 Chapter 6. Encrypting a swap partition 11 Chapter 7. Encrypting a temporary file system Chapter 8. Migrating data Chapter 9. Encrypting file systems using ecryptfs Create a single mountpoint for upper and lower file systems Using remote file systems for ecryptfs lower file system Create a single user ecryptfs mount Chapter 10. Protecting your data at rest with Red Hat Enterprise Linux Scope, requirements, and support Before you encrypt Selecting partitions to encrypt Encrypting partitions using dm-crypt Encrypting data partitions Encrypting a swap partition Encrypting a temporary file system Migrating data Encrypting file systems using ecryptfs Create a single mountpoint for upper and lower file systems Using remote file systems for ecryptfs lower file system Create a single user ecryptfs mount Appendix A. Troubleshooting tips Appendix B. References Notices Trademarks Copyright IBM Corp iii

6 iv Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

7 Chapter 1. Scope, requirements, and support This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Systems to which this information applies System x running Linux Intended audience This paper is intended for Linux system administrators with a moderate level of knowledge of system administration. Scope and purpose This paper shows you how to encrypt your data to help prevent data leaks that can harm your customers and organization. All the steps demonstrated here are tested in Red Hat Enterprise Linux 5.2 and 5.4 running on System x. Hardware and software requirements cryptsetup-luks-*.rpm is required. Other considerations To be able to create an encrypted partition for new data, swap partition, temporary file system, or existing data, extra space in the machine is required. For example purposes, assume that the RHEL5.2 and 5.4 machine used in examples uses logical volumes to manage disk space and has enough extra space available. By entering vgdisplay command, you can see in the return what volume groups exist and how much space is still available on your system. In our example, there is only one volume group, system, in the machine and the system has GB of free space available for creating more logical volumes: # vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 9 VG Access read/write VG Status resizable MAX LV 0 Cur LV 6 Open LV 3 Max PV 0 Cur PV 1 Act PV 1 VG Size GB PE Size MB Total PE 1081 Alloc PE / Size 658 / GB Free PE / Size 423 / GB VG UUID r0n8he-pqlc-sl1k-1dwy-30iq-0ypp-gune6l Copyright IBM Corp

8 Also assume that there is a directory named /home/testuser on the system. Author names George Wilson Other contributors Monza Lui Kersten Richter Subrata Modak IBM Services Linux offers flexibility, options, and competitive total cost of ownership with a world class enterprise operating system. Community innovation integrates leading edge technologies and best practices into Linux. IBM is a leader in the Linux community with over 600 developers in the IBM Linux Technology Center working on over 100 open source projects in the community. IBM supports Linux on all IBM servers, storage, and middleware, offering the broadest flexibility to match your business needs. For more information about IBM and Linux, visit us at ibm.com/linux. IBM Support Questions and comments regarding this documentation may be posted on the DeveloperWorks Security Blueprint Community Forum: IBM Linux Security Blueprint Support Forum ( forum.jspa?forumid=1271) The IBM developerworks discussion forums let you ask questions, share knowledge, ideas, and opinions about technologies and programming techniques with other developerworks users. Use the forum content at your own risk. While IBM will attempt to provide a timely response to all postings, the use of this DeveloperWorks forum does not guarantee a response to every question that is posted, nor do we validate the answers or the code that are offered. Typographic conventions The following typographic conventions are used in this blueprint: Bold Italics Monospace Identifies commands, subroutines, keywords, files, structures, directories, and other items whose names are predefined by the system. Also identifies graphical objects such as buttons, labels, and icons that the user selects. Identifies parameters whose actual names or values are to be supplied by the user. Identifies examples of specific data values, examples of text similar to what you might see displayed, examples of portions of program code similar to what you might write as a programmer, messages from the system, or information you should actually type. 2 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

9 Chapter 2. Before you encrypt Encryption is a systematic scrambling of data that renders it practically unusable without possession of a small piece of data known as the key. It is easy to decrypt encrypted data with the key but very difficult without it. Automatically encrypting files or devices when data is stored enhances the privacy of your data in case of stolen or lost data. There are some steps you should take prior to encrypting your data. First, identify your sensitive data which potentially needs protection. Then, categorize that data according to its security needs. For example, you may want to identify sensitive customer data such as names, addresses, and credit card numbers as requiring more protection than the content of your static Web pages. All enterprises, even small ones, should have a comprehensive information security policy. After your information is categorized, you should establish some security policies for how to handle your various categories of sensitive data. For example, you may establish a policy that company financial data should not be stored on the same machine that hosts the company Web site. You may want to ensure that customer private data is stored in encrypted format in a separate subdirectory to which only certain employees have access. The information security policy should include the entire data lifecycle: of data creation, storage, and disposal. No security policy is complete without defining a data backup strategy. If the working set of your mission critical information is destroyed, you must have a way to recover it. Backups should be performed on a regular basis. There are various methodologies for doing so, which are out of the scope of this paper. Remember to apply your security policy to your backup data with as much care as you apply to your online data. Once you determine your data security categories and policies, you might decide that encryption can play a role in enforcing the policy. Part of the policy will then need to state how encryption keys will be handled. You should consider backing up your encryption keys to secondary storage that can be physically secured. For enterprises requiring access to data even when an employee becomes unavailable for some reason, you might want to consider a framework that escrows keys of individual users. Though a discussion of key escrow is beyond the bounds of this paper, there are resources available from IBM to help you manage more complex enterprise environments. Note that no software can prevent successful attacks by determined attackers with physical access to a machine given current general-purpose computer architectures. For example, encryption keys must be stored in plaintext in memory while they are being used to encrypt or decrypt data. Stored in memory, these keys are vulnerable to memory probing attacks, which can include cooling the memory, removing the power, and transferring the memory to another machine for perusal at the attacker's convenience. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Copyright IBM Corp

10 4 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

11 Chapter 3. Selecting partitions to encrypt Typically, encrypting persistent system data such as executable programs is not worth the overhead as that data is not typically sensitive. The granularity of your ability to encrypt only sensitive data depends on how you partition your file system. For example, if you have a single large root partition with no room on the physical device, you won't have the option to encrypt the /home device as easily as if you had created a separate /home file system to begin with. It is therefore best from an encryption perspective to assign the file system's main subdirectories to separate disk partitions. In addition, consider using logical volumes to simplify and provide the most flexibility in managing your partitions For a typical Linux file system layout, keep the following recommendations in mind when deciding what you should encrypt: Table 1. Encrypting recommendations Recommendation Don't encrypt: Perhaps encrypt: Recommend encrypting: Strongly recommend encrypting: File system /usr, /opt, or/ (root) /var swap, /tmp, /var/tmp /home/${user} Alternatively, encrypt /home/{user}/confidential. If a system partition you want to encrypt is required for system operation, you might have to boot into single-user mode to manage it. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Copyright IBM Corp

12 6 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

13 Chapter 4. Encrypting partitions using dm-crypt An encrypted partition scrambles your data, rendering an entire partition unreadable without possession of an encryption key. Creating an encrypted partition on modern Linux systems is fairly straightforward with dm-crypt. In RHEL 5, the /etc/rc.sysinit script supports clean management of encrypted partitions. The /etc/crypttab file specifies the devices that are to be set up with encryption. The encrypted devices are then referenced in the /etc/fstab file and mounted during fstab processing by the /etc/rc.sysinit script. The first field of /etc/crypttab specifies the name of the device used to access the original data (plaintext). It is created in the /dev/mapper directory. The second field specifies the underlying device that stores the encrypted data (ciphertext). Raw dm-crypt or LUKS partitions may be specified, but no cryptsetup options can be specified if it is a LUKS partition. The third field specifies the key file. An empty field or the keyword none requires a prompt at boot time. Swap and temporary devices can use /dev/urandom for a random key. The fourth field specifies options. swap causes the device to be formatted for swap and tmp causes the device to be formatted with ext2 for use as a tmp file system. Raw dm-crypt device options are converted to cryptsetup options and passed to cryptsetup. See the cryptsetup(8) man page for more details on cryptsetup. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Copyright IBM Corp

14 8 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

15 Chapter 5. Encrypting data partitions This topic describes encrypting data partitions. About this task Before beginning this task, be sure that you have read the Assumptions topic. Procedure 1. Switch users to become the root user: su - 2. Retrieve the names of your volume groups and related information, such as how much space left is available: vgdisplay 3. Allocate a new volume (in this case, a logical volume) to contain the encrypted data: lvcreate -L 1g -n encryptedlv VolGroup00 dm-crypt works by transparently translating (in the kernel) between an encrypted partition and a logical unencrypted device-mapper device. In this example, 1g is size of the logical volume to be created, in gigabypes; encryptedlv is the user-given name of the new logical volume; and VolGroup00 is the name of the volume group where the new logical volume is to be created. A new logical volume named /dev/mapper/volgroup00-encryptedlv is created. 4. Initialize the new logical volume to be a Linux Unified Key Setup (LUKS) partition. You are prompted to enter a passphrase. cryptsetup luksformat /dev/mapper/volgroup00-encryptedlv Tip: v Take care when entering the value luksformat. It is case sensitive. v For more information about LUKS, see 5. Answer YES and enter the passphrase twice. WARNING! ======== This will overwrite data on /dev/mapper/volgroup00-tmplv irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command successful. Tip: v Type YES, not yes. v Do not forget your encryption passphrase. There is no easy way to recover either the password or the data. v When selecting a passphrase, be sure to select one that is strong. For more information about passphrases and passwords, see Protecting passwords: Part Create a logical device-mapper device, mounted to the LUKS-encrypted partition. Data will be read and written via this new device-mapper device to and from the encrypted partition. In this example, luksdev is the user given name of the mapping name for the opened LUKS partition. cryptsetup luksopen /dev/mapper/volgroup00-encryptedlv luksdev Copyright IBM Corp

16 A new device-mapper device named /dev/mapper/luksdev appears. 7. Format the new logical device with your favorite file system. The following example used the ext3 file system: mkfs.ext3 /dev/mapper/luksdev 8. Create a mountpoint for mounting the new logical device so that data can be read and written to the LUKS-encrypted partition via this mountpoint. mkdir /home/testuser/encrypted-data-partition 9. Mount the file system. mount /dev/mapper/luksdev /home/testuser/encrypted-data-partition 10. Add one entry each to the /etc/crypttab file and the /etc/fstab file to make the mounts persistent across boots. If the /etc/crypttab file does not exist, you need to create it. /etc/crypttab: #Name Device Keyfile Options luksdev /dev/mapper/volgroup00-luksdev /etc/fstab: /dev/mapper/luksdev /home/testuser/encrypted-data-partition ext2 defaults 0 0 Results The next time that you reboot the system, you will be prompted for the encrypted data device's passphrase. Assuming that you provide the correct passphrase to decrypt the data, the device will be automounted. Note that setting up encrypted volumes to prompt for a passphrase pauses system boot until the passphrase is entered. If the machine is physically secure and you don't want the boot sequence to wait for a passphrase to be entered, consider using a key file. To add a key file, add the path to your key file to the end of the command cryptsetup luksformat /dev/mapper/volgroup00-encryptedlv in step 4. See the cryptsetup man page for details. However, using a key file leaves the key unprotected on disk and subject to easy recovery unless you store it on a separate encrypted partition. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the 10 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

17 Chapter 6. Encrypting a swap partition Similar to the encrypted partition containing an ordinary file system, encrypted swap devices prevent disclosure of sensitive data paged out to disk by the Linux virtual memory manager. About this task Before you start, note that this configuration is meant to create a new swap partition at every reboot. A new random key file is created in every reboot and, therefore, booting up the system does not prompt for the user input of a passphrase, and does not pause the boot sequence. You will need to create the logical volume for the swap partition and change two files (/etc/crypttab and /etc/fstab). The rest of the process is automated. Procedure 1. Create a new logical volume to act as a swap partition. This example creates a1gbswap partition on the existing volume group VolGroup00. lvcreate -L 1g -n swaplv VolGroup00 2. If it is not already created, create the /etc/crypttab file. Add an entry to /etc/crypttab file. You can use any name to replace cr_swaplv, but it must match what is in the /etc/fstab file. #Name Device Keyfile Options cr_swaplv /dev/mapper/volgroup00-swaplv /dev/urandom cipher=aes-cbc-essiv:sha256,size=128,swap 3. Add an entry to the /etc/fstab file. /dev/mapper/cr_swaplv swap swap defaults 0 0 The next time you boot the system and the /etc/rs.sysinit script executes, it creates a raw dm-crypt device with a random key and formats it as a swap device. During /etc/fstab processing, the swap device is activated. 4. Reboot the system. 5. Verify that the swap space is encrypted. swapon -s You should see a new entry for the added swap file system. You can see it listed below in the second entry, in our example. # swapon -s Filename Type Size Used Priority /dev/mapper/system-swap partition /dev/mapper/cr_swaplv partition What to do next After you are satisfied that your encrypted swap is working correctly, remove the unencrypted swap space from the system's /etc/fstab file. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Copyright IBM Corp

18 12 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

19 Chapter 7. Encrypting a temporary file system Much like the swap partition, the ephemeral data stored in the temporary file systems might contain sensitive data. About this task Assuming their contents are completely volatile, temporary file systems can be protected with random keys much like swap partitions, except they need to be formatted as file systems and mounted to a mount point. Before you start, note that this configuration is temporary and is meant to create a new file system in every reboot. A new random key file is created in every reboot. When you boot the system, you will not be prompted for a passphrase. To encrypt a temporary file system, such as /tmp: Procedure 1. Allocate a new volume for your temporary file system. This example shows an 8 GB temporary file system created on an existing VolGroup00 volume group. lvcreate -L 8g -n tmplv VolGroup00 2. If it is not already created, create the /etc/crypttab file. Add an entry to the /etc/crypttab file. Note that you can use any name to replace cr_tmplv, but it must match what is in the /etc/fstab file. #Name Device Keyfile Options cr_tmplv /dev/mapper/volgroup00-tmplv /dev/urandom cipher=aes-cbc-essiv:sha256,size=128,tmp Tip: Don't confuse the /dev/random file with the /dev/urandom file. The /dev/urandom file is used. Using the /dev/random file might cause the system to hang during boot. 3. Add an entry to the /etc/fstab file. This example mounts the temporary file system to /tmp Note that ext2 is mandatory in this case. You cannot use any other file systems. /dev/mapper/cr_tmplv /tmp ext2 defaults Reboot the system What to do next If the system boots without prompting you to enter a passphrase to unlock this partition and mount shows that the /dev/mapper/cr_tmplv device is mounted on /tmp, the encrypted temporary file system has been successfully set up. # mount grep tmp /dev/mapper/cr_tmplv on /tmp type ext2(rw) Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Copyright IBM Corp

20 14 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

21 Chapter 8. Migrating data Adding an empty encrypted partition is easy enough. But what if you have data on an existing partition that you want to encrypt? Unfortunately, there is no easy answer. You will have to backup the data, create the encrypted partition, and restore the data to it. This means you have to have sufficient disk space to store the data while the existing partition is being recreated. About this task Migrate the /home directory with the following steps: Procedure 1. Switch users to become the root user: su - 2. Create or add a partition of sufficient size to contain the data temporarily. For this example, the spare space is called /tempspace. 3. Save the data in the /home directory with the tar command. tar -C / -cpzf /tempspace/home.tar.gz /home 4. Verify that the archive is completed before proceeding. For example, you can use the tar -d command to compare the archive contents against the file system. tar -C / -dvzf /tempspace/home.tar.gz /home 5. Unmount the /home directory if your/home directory is mounted another device. Skip this step if you have a single / directory. umount /home 6. Retrieve the names of your volume groups using the vgdisplay command. You will need this information for the following steps. vgdisplay 7. Create the LUKS volume. This example creates a logical volume of 1GB named homelv in the existing volume group VolGroup00. cryptsetup luksformat /dev/mapper/volgroup00-homelv Note: These steps are similar to the steps in the Encrypting data partitions procedure. Refer to Chapter 5, Encrypting data partitions, on page 9 the for more details. 8. Open the LUKS partition. cryptsetup luksopen /dev/mapper/volgroup00-homelv homedev 9. Create the file system. In this example, uses ext3. mkfs.ext3 /dev/mapper/homedev 10. Mount the file system. mount /dev/mapper/homedev /home 11. Restore the previous data. tar -C / -xpzf /tempspace/home.tar.gz 12. Compare the archive and file system once again. tar -C / -dvzf /tempspace/home.tar.gz /home What to do next After the data is restored, set up the file system for automated mount as you did for the encrypted data partition in the Encrypting data partitions topic. When you are satisfied with the setup, you can remove Copyright IBM Corp

22 the /tempspace directory and destroy the temporary file system to free the space. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the 16 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

23 Chapter 9. Encrypting file systems using ecryptfs While partition-level encryption adequately protects data from leaks, it does so with less than maximal efficiency. For example, binaries may not be confidential and may not require protection. With the dm-crypt approach, the binaries are unnecessarily encrypted. Encryption at the file level rather than at the partition level results in greater encryption efficiency. In Fedora 8, RHEL 5.2, and their later versions, a file system known as ecryptfs is available, and it performs encryption on a per-file basis. About this task Be aware that ecryptfs is a Technology Preview in RHEL 5.2 and is not recommended for use in production systems. Currently ecryptfs supports only mount-wide key, either using a passphrase or external key modules. However, each of the files is encrypted with its own File Encryption Key (FEK) that is then wrappered by the File Key Encryption Key (FKEK) derived from the mount-wide key. Moreover, ecryptfs is stackable and can be used on top of an existing file system. You can experiment with ecryptfs with the following steps: Procedure 1. Switch users to become the root user: su - 2. Ensure ecryptfs userspace is installed: rpm -qa grep ecryptfs If ecryptfs userspace is installed, the following is returned: ecryptfs-utils-41-1.el5 ecryptfs-utils-41-1.el5 If ecryptfs userspace is not installed, enter the following: yum install ecryptfs-utils 3. Install the kernel keyring utilities package if it is not already installed. yum install keyutils 4. Ensure the ecryptfs kernel module is loaded. modprobe ecryptfs lsmod grep ecryptfs 5. Make a directory to hold the encrypted data. This is known as a lower file system in ecryptfs parlance. mkdir /home/testuser/lower 6. Make a directory to access the original data (plaintext). This is the upper file system. mkdir /home/testuser/upper 7. Mount the lower file system on the upper file system. mount -t ecryptfs /home/testuser/lower /home/testuser/upper 8. Follow the prompts to establish the encryption method, algorithm, keysize, and so on. On the first attempt, try the mount-wide passphrase. You can experiment with other methods later. Select key type to use for newly created files: 1) passphrase 2) openssl Selection: 1 9. Enter a passphrase at the next prompt. As always, make sure to choose a strong passphrase if you are going to use the directory to store sensitive data. 10. Chose an encryption algorithm. Copyright IBM Corp

24 Select cipher: 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded) 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded) 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded) Selection [aes]: Select the key size. Select key bytes: 1) 16 2) 32 Selection [16]: Permit plain-text. This allows a file that is unencrypted in the lower file system to be used in the upper file system. Enable plaintext passthrough (y/n): y 13. Complete the mount. Ordinarily, you have no way of knowing if you are creating a new encrypted directory or if you provided the wrong passphrase to ecryptfs. The ecryptfs mount helper attempts to protect you from inadvertently overwriting your existing encrypted directories by caching key signatures and comparing the one you just provided with those in the cache. If no match is found, you will see a warning. In this example, the directory was just created, and it is safe to proceed. Enable plaintext passthrough (y/n): y Attempting to mount with the following options: ecryptfs_passthrough ecryptfs_key_bytes=16 ecryptfs_cipher=blowfish ecryptfs_sig=d81ae6e0fb3148b0 WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt], it looks like you have never mounted with this key before. This could mean that you have typed your passphrase wrong. Would you like to proceed with the mount (yes/no)? yes 14. Store the key signature in the ecryptfs signature cache. You should cache the signature to prevent accidentally overwriting your existing encrypted directories. But the cached signature could also be used in an offline dictionary attack against your key. You should consider choosing strong keys and using the signature cache. Would you like to append sig [d81ae6e0fb3148b0] to [/root/.ecryptfs/sig-cache.txt] in order to avoid this warning in the future (yes/no)? yes Successfully appended new sig to user sig cache file Mounted ecryptfs Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Create a single mountpoint for upper and lower file systems Because Linux makes the last mounted file system on a mountpoint accessible, you can use a single mountpoint for both lower and upper file systems. This is safer than separate directories as a single directory reused as the mountpoint makes it easier to prevent inadvertent access to the lower file system. 18 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

25 About this task SeeChapter 9, Encrypting file systems using ecryptfs, on page 17 for details about using ecryptfs. To create a single mountpoint for upper and lower file systems, complete the following steps: Procedure 1. Make the lower directory to contain the encrypted data. mkdir /home/testuser/data 2. Mount the upper file system over the lower directory. mount -t ecryptfs /home/testuser/data /home/testuser/data Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Using remote file systems for ecryptfs lower file system The ecryptfs lower file system can also be located on top of remote file systems, so that you can perform encryption of NFS directories, for example. About this task SeeChapter 9, Encrypting file systems using ecryptfs, on page 17 for details about using ecryptfs. Procedure 1. Mount the remote NFS file system on the local mountpoint. mount -t nfs remotehost:/remotedir /localdir 2. Make the lower directory to contain the encrypted data. mkdir /localdir/data 3. Mount the upper file system over the lower directory. mount -t ecryptfs /localdir/data /localdir/data Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Create a single user ecryptfs mount Users can create their own ecryptfs mounts. Additionally, you can bypass prompting. About this task SeeChapter 9, Encrypting file systems using ecryptfs, on page 17 for details about using ecryptfs. Note: Because ecryptfs uses the kernel keyring to manage its keys, you need to store your key in the keyring with a utility called ecryptfs-manager. To create a single user ecryptfs mount, follow these steps: Chapter 9. Encrypting file systems using ecryptfs 19

26 Procedure 1. Create a directory in a user's home directory. mkdir /home/testuser/confidential 2. Overlay the ecryptfs file system on top of the directory created in step 1. mount -t ecryptfs /home/testuser/confidential /home/testuser/confidential 3. Use the passphrase key type that you created. When prompted for the passphrase, use the same passphrase as the user's password. 4. Find the mount options. grep /home/testuser/confidential /etc/mtab You will see a return similar to the following: /home/testuser/confidential /home/testuser/confidential ecryptfs rw,noexec,nosuid,nodev,ecryptfs_sig=d458c8a4923bfb4a,ecryptfs_key_bytes=16, ecryptfs_cipher=twofish,ecryptfs_passthrough Open /etc/fstab in your favorite text editor and append the last line, adding the user and noauto options. /home/testuser/confidential /home/testuser/confidential ecryptfs noauto,user,rw,noexec,nosuid,nodev,ecryptfs_sig=d458c8a4923bfb4a, ecryptfs_key_bytes=16,ecryptfs_cipher=twofish,ecryptfs_passthrough Unmount the file system. umount /home/testuser/confidential 7. Add the ecryptfs PAM module to a PAM configuration file. On RHEL, /etc/pam.d/system-auth is a good candidate. Place the PAM module in the auth section, just before pam_deny. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_ecryptfs.so auth required pam_deny.so 8. Switch to the user. su - testuser 9. Add the user's passphrase to the kernel keyring. ecryptfs-manager 10. Follow the prompts to add a mount-wide passphrase, like you did when creating the ecryptfs file system. ecryptfs key management menu Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Abort management Make selection: 1 Mount-wide passphrase: Confirm passphrase: Using the default salt value 11. Test the mount. Use the -i flag to suppress the running mount helper so that it uses the key stored in the kernel keyring rather than prompting you for a key. mount -i ~/confidential The mount succeeds. 12. Add the mount command to the user's ~/.bash_profile. Note: If the file system is already mounted, skip this step. 20 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

27 CONFIDENTIAL_DIR=${HOME}/confidential if! grep $CONFIDENTIAL_DIR /proc/mounts >/dev/null 2>&1; then mount -i $CONFIDENTIAL_DIR fi 13. Unmount the directory. umount ~/confidential 14. Log out completely. 15. Log in as the user that you set up. 16. You should see the confidential file system mounted. What to do next You should be able to unmount the file system and remount the file system with the -i command at any time without having to supply the passphrase. ecryptfs obtains the passphrase from the kernel keyring rather than prompting. It is not necessary for the system administrator to know user passphrases. A user can invoke ecryptfs-manager, enter a passphrase, and give the key signature to the administrator. The administrator can the use the key signature the user provided to setup /etc/fstab for the user's ecryptfs mount. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Chapter 9. Encrypting file systems using ecryptfs 21

28 22 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

29 Chapter 10. Protecting your data at rest with Red Hat Enterprise Linux This blueprint provides concrete advice on how to use encryption to protect your data at rest and vastly improve your organization's resistance to data leaks. This blueprint demonstrates step by step how to setup a new encrypted data partition, swap partition, temporary file system, and how to migrate your old data to a new encrypted partition. Also, the blueprint shows you how to use a new file system ecryptfs, to encrypt your data. Key tools and technologies discussed in this demonstration include ecryptfs, dm-crypt, cryptsetup, and the /etc/crypttab file. Scope, requirements, and support This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Systems to which this information applies System x running Linux Intended audience This paper is intended for Linux system administrators with a moderate level of knowledge of system administration. Scope and purpose This paper shows you how to encrypt your data to help prevent data leaks that can harm your customers and organization. All the steps demonstrated here are tested in Red Hat Enterprise Linux 5.2 and 5.4 running on System x. Hardware and software requirements cryptsetup-luks-*.rpm is required. Other considerations To be able to create an encrypted partition for new data, swap partition, temporary file system, or existing data, extra space in the machine is required. For example purposes, assume that the RHEL5.2 and 5.4 machine used in examples uses logical volumes to manage disk space and has enough extra space available. By entering vgdisplay command, you can see in the return what volume groups exist and how much space is still available on your system. In our example, there is only one volume group, system, in the machine and the system has GB of free space available for creating more logical volumes: # vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 9 VG Access read/write VG Status resizable MAX LV 0 Copyright IBM Corp

30 Cur LV 6 Open LV 3 Max PV 0 Cur PV 1 Act PV 1 VG Size GB PE Size MB Total PE 1081 Alloc PE / Size 658 / GB Free PE / Size 423 / GB VG UUID r0n8he-pqlc-sl1k-1dwy-30iq-0ypp-gune6l Also assume that there is a directory named /home/testuser on the system. Author names George Wilson Other contributors Monza Lui Kersten Richter Subrata Modak IBM Services Linux offers flexibility, options, and competitive total cost of ownership with a world class enterprise operating system. Community innovation integrates leading edge technologies and best practices into Linux. IBM is a leader in the Linux community with over 600 developers in the IBM Linux Technology Center working on over 100 open source projects in the community. IBM supports Linux on all IBM servers, storage, and middleware, offering the broadest flexibility to match your business needs. For more information about IBM and Linux, visit us at ibm.com/linux. IBM Support Questions and comments regarding this documentation may be posted on the DeveloperWorks Security Blueprint Community Forum: IBM Linux Security Blueprint Support Forum ( forum.jspa?forumid=1271) The IBM developerworks discussion forums let you ask questions, share knowledge, ideas, and opinions about technologies and programming techniques with other developerworks users. Use the forum content at your own risk. While IBM will attempt to provide a timely response to all postings, the use of this DeveloperWorks forum does not guarantee a response to every question that is posted, nor do we validate the answers or the code that are offered. Typographic conventions The following typographic conventions are used in this blueprint: Bold Italics Identifies commands, subroutines, keywords, files, structures, directories, and other items whose names are predefined by the system. Also identifies graphical objects such as buttons, labels, and icons that the user selects. Identifies parameters whose actual names or values are to be supplied by the user. 24 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

31 Monospace Identifies examples of specific data values, examples of text similar to what you might see displayed, examples of portions of program code similar to what you might write as a programmer, messages from the system, or information you should actually type. Before you encrypt Encryption is a systematic scrambling of data that renders it practically unusable without possession of a small piece of data known as the key. It is easy to decrypt encrypted data with the key but very difficult without it. Automatically encrypting files or devices when data is stored enhances the privacy of your data in case of stolen or lost data. There are some steps you should take prior to encrypting your data. First, identify your sensitive data which potentially needs protection. Then, categorize that data according to its security needs. For example, you may want to identify sensitive customer data such as names, addresses, and credit card numbers as requiring more protection than the content of your static Web pages. All enterprises, even small ones, should have a comprehensive information security policy. After your information is categorized, you should establish some security policies for how to handle your various categories of sensitive data. For example, you may establish a policy that company financial data should not be stored on the same machine that hosts the company Web site. You may want to ensure that customer private data is stored in encrypted format in a separate subdirectory to which only certain employees have access. The information security policy should include the entire data lifecycle: of data creation, storage, and disposal. No security policy is complete without defining a data backup strategy. If the working set of your mission critical information is destroyed, you must have a way to recover it. Backups should be performed on a regular basis. There are various methodologies for doing so, which are out of the scope of this paper. Remember to apply your security policy to your backup data with as much care as you apply to your online data. Once you determine your data security categories and policies, you might decide that encryption can play a role in enforcing the policy. Part of the policy will then need to state how encryption keys will be handled. You should consider backing up your encryption keys to secondary storage that can be physically secured. For enterprises requiring access to data even when an employee becomes unavailable for some reason, you might want to consider a framework that escrows keys of individual users. Though a discussion of key escrow is beyond the bounds of this paper, there are resources available from IBM to help you manage more complex enterprise environments. Note that no software can prevent successful attacks by determined attackers with physical access to a machine given current general-purpose computer architectures. For example, encryption keys must be stored in plaintext in memory while they are being used to encrypt or decrypt data. Stored in memory, these keys are vulnerable to memory probing attacks, which can include cooling the memory, removing the power, and transferring the memory to another machine for perusal at the attacker's convenience. Chapter 10. Protecting your data at rest with Red Hat Enterprise Linux 25

32 Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Selecting partitions to encrypt Typically, encrypting persistent system data such as executable programs is not worth the overhead as that data is not typically sensitive. The granularity of your ability to encrypt only sensitive data depends on how you partition your file system. For example, if you have a single large root partition with no room on the physical device, you won't have the option to encrypt the /home device as easily as if you had created a separate /home file system to begin with. It is therefore best from an encryption perspective to assign the file system's main subdirectories to separate disk partitions. In addition, consider using logical volumes to simplify and provide the most flexibility in managing your partitions For a typical Linux file system layout, keep the following recommendations in mind when deciding what you should encrypt: Table 2. Encrypting recommendations Recommendation Don't encrypt: Perhaps encrypt: Recommend encrypting: Strongly recommend encrypting: File system /usr, /opt, or/ (root) /var swap, /tmp, /var/tmp /home/${user} Alternatively, encrypt /home/{user}/confidential. If a system partition you want to encrypt is required for system operation, you might have to boot into single-user mode to manage it. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Encrypting partitions using dm-crypt An encrypted partition scrambles your data, rendering an entire partition unreadable without possession of an encryption key. Creating an encrypted partition on modern Linux systems is fairly straightforward with dm-crypt. In RHEL 5, the /etc/rc.sysinit script supports clean management of encrypted partitions. The /etc/crypttab file specifies the devices that are to be set up with encryption. The encrypted devices are then referenced in the /etc/fstab file and mounted during fstab processing by the /etc/rc.sysinit script. The first field of /etc/crypttab specifies the name of the device used to access the original data (plaintext). It is created in the /dev/mapper directory. The second field specifies the underlying device that stores the encrypted data (ciphertext). Raw dm-crypt or LUKS partitions may be specified, but no cryptsetup options can be specified if it is a LUKS partition. 26 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

33 The third field specifies the key file. An empty field or the keyword none requires a prompt at boot time. Swap and temporary devices can use /dev/urandom for a random key. The fourth field specifies options. swap causes the device to be formatted for swap and tmp causes the device to be formatted with ext2 for use as a tmp file system. Raw dm-crypt device options are converted to cryptsetup options and passed to cryptsetup. See the cryptsetup(8) man page for more details on cryptsetup. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Encrypting data partitions This topic describes encrypting data partitions. About this task Before beginning this task, be sure that you have read the Assumptions topic. Procedure 1. Switch users to become the root user: su - 2. Retrieve the names of your volume groups and related information, such as how much space left is available: vgdisplay 3. Allocate a new volume (in this case, a logical volume) to contain the encrypted data: lvcreate -L 1g -n encryptedlv VolGroup00 dm-crypt works by transparently translating (in the kernel) between an encrypted partition and a logical unencrypted device-mapper device. In this example, 1g is size of the logical volume to be created, in gigabypes; encryptedlv is the user-given name of the new logical volume; and VolGroup00 is the name of the volume group where the new logical volume is to be created. A new logical volume named /dev/mapper/volgroup00-encryptedlv is created. 4. Initialize the new logical volume to be a Linux Unified Key Setup (LUKS) partition. You are prompted to enter a passphrase. cryptsetup luksformat /dev/mapper/volgroup00-encryptedlv Tip: v Take care when entering the value luksformat. It is case sensitive. v For more information about LUKS, see 5. Answer YES and enter the passphrase twice. WARNING! ======== This will overwrite data on /dev/mapper/volgroup00-tmplv irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command successful. Chapter 10. Protecting your data at rest with Red Hat Enterprise Linux 27

34 Tip: v Type YES, not yes. v Do not forget your encryption passphrase. There is no easy way to recover either the password or the data. v When selecting a passphrase, be sure to select one that is strong. For more information about passphrases and passwords, see Protecting passwords: Part Create a logical device-mapper device, mounted to the LUKS-encrypted partition. Data will be read and written via this new device-mapper device to and from the encrypted partition. In this example, luksdev is the user given name of the mapping name for the opened LUKS partition. cryptsetup luksopen /dev/mapper/volgroup00-encryptedlv luksdev A new device-mapper device named /dev/mapper/luksdev appears. 7. Format the new logical device with your favorite file system. The following example used the ext3 file system: mkfs.ext3 /dev/mapper/luksdev 8. Create a mountpoint for mounting the new logical device so that data can be read and written to the LUKS-encrypted partition via this mountpoint. mkdir /home/testuser/encrypted-data-partition 9. Mount the file system. mount /dev/mapper/luksdev /home/testuser/encrypted-data-partition 10. Add one entry each to the /etc/crypttab file and the /etc/fstab file to make the mounts persistent across boots. If the /etc/crypttab file does not exist, you need to create it. /etc/crypttab: #Name Device Keyfile Options luksdev /dev/mapper/volgroup00-luksdev /etc/fstab: /dev/mapper/luksdev /home/testuser/encrypted-data-partition ext2 defaults 0 0 Results The next time that you reboot the system, you will be prompted for the encrypted data device's passphrase. Assuming that you provide the correct passphrase to decrypt the data, the device will be automounted. Note that setting up encrypted volumes to prompt for a passphrase pauses system boot until the passphrase is entered. If the machine is physically secure and you don't want the boot sequence to wait for a passphrase to be entered, consider using a key file. To add a key file, add the path to your key file to the end of the command cryptsetup luksformat /dev/mapper/volgroup00-encryptedlv in step 4. See the cryptsetup man page for details. However, using a key file leaves the key unprotected on disk and subject to easy recovery unless you store it on a separate encrypted partition. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Encrypting a swap partition Similar to the encrypted partition containing an ordinary file system, encrypted swap devices prevent disclosure of sensitive data paged out to disk by the Linux virtual memory manager. 28 Blueprints: Protecting your data at rest with Red Hat Enterprise Linux on System x

35 About this task Before you start, note that this configuration is meant to create a new swap partition at every reboot. A new random key file is created in every reboot and, therefore, booting up the system does not prompt for the user input of a passphrase, and does not pause the boot sequence. You will need to create the logical volume for the swap partition and change two files (/etc/crypttab and /etc/fstab). The rest of the process is automated. Procedure 1. Create a new logical volume to act as a swap partition. This example creates a1gbswap partition on the existing volume group VolGroup00. lvcreate -L 1g -n swaplv VolGroup00 2. If it is not already created, create the /etc/crypttab file. Add an entry to /etc/crypttab file. You can use any name to replace cr_swaplv, but it must match what is in the /etc/fstab file. #Name Device Keyfile Options cr_swaplv /dev/mapper/volgroup00-swaplv /dev/urandom cipher=aes-cbc-essiv:sha256,size=128,swap 3. Add an entry to the /etc/fstab file. /dev/mapper/cr_swaplv swap swap defaults 0 0 The next time you boot the system and the /etc/rs.sysinit script executes, it creates a raw dm-crypt device with a random key and formats it as a swap device. During /etc/fstab processing, the swap device is activated. 4. Reboot the system. 5. Verify that the swap space is encrypted. swapon -s You should see a new entry for the added swap file system. You can see it listed below in the second entry, in our example. # swapon -s Filename Type Size Used Priority /dev/mapper/system-swap partition /dev/mapper/cr_swaplv partition What to do next After you are satisfied that your encrypted swap is working correctly, remove the unencrypted swap space from the system's /etc/fstab file. Related reference: Chapter 1, Scope, requirements, and support, on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the Encrypting a temporary file system Much like the swap partition, the ephemeral data stored in the temporary file systems might contain sensitive data. About this task Assuming their contents are completely volatile, temporary file systems can be protected with random keys much like swap partitions, except they need to be formatted as file systems and mounted to a mount point. Chapter 10. Protecting your data at rest with Red Hat Enterprise Linux 29