Devin Reade |
|
GNO Consortium | Home | GNO/ME |
NOTE: The mechanisms described here do not apply to new installations of CentOS/RHEL versions 5.4 and later, as crypto is now available in those later distributions by default. A machine that has been installed with these mechanisms can be upgraded through to (at least) 5.4, however the mechanisms are different. For information on using a USB device to hold the LUKS key for later versions, the documents for CentOS/RHEL 5.4 to 5.10 and CentOS/RHEL 6.5+. I leave the information on this page in place for historical reasons.
This document describes how to set up a CentOS (and therefore presumably a Red Had Enterprise) machine using encrypted disks, including for root and swap, if desired. In a fully encrypted configuration, this includes allowing the proper behavior of hibernate, suspend, and resume.
This kind of functionality has been requested from the Red Hat for quite a while, and I understand that work is on-going, but it still isn't available out of the box. When it eventually becomes available, the solution may (and probably will) look different from this, as it has to be much more general for the wide user base. However, this works for me and hopefully it will work for you.
I have used this mechanism on laptops, workstations, and servers. There can be differences in these configurations, depending on your operational requirements. Here, I will be showing two different configurations, which I'll name the Laptop and Server configurations (but please read this page before you move on to those examples). These names are arbitrary and the configuration details are not necessarily mutually exclusive; you may decide to implement elements from one with elements of the other for your particular configuration.
Below I give a technical overview of the subject, followed by a comparison of the two configurations.
The mechanism described here is based on LVM-over-LUKS; the (majority of the) disk is encrypted with LUKS, layered with LVM, and then the remaining filesystems are placed on LVM as logical volumes.
Some other resources describe the inverse: LUKS over LVM. Some advantages of the method described in this document (LVM over LUKS) are:
The procedure is generally as follows (if you are using software RAID, that detail is not shown here):
We start with a partitioning scheme
where we have a small /boot partition at the beginning
of the disk, followed by an unused partition,
and finally a partition upon which we install the unencrypted OS using
LVM vg2. This is shown in
Figure 1, below.
Next, as shown in Figure 2, we set up encryption on what was previously the unused partition, and create a volume group (vg1) on top of the encryption.
If we're going to be encrypting all of the filesystems, we then move all of the filesystems that were originally on the unencrypted partition (vg2) onto the encrypted partition (vg1). This is shown in Figure 3.
If we're leaving some filesystems unencrypted, then only some of the filesystems get moved and we are done the partitioning portion of our work at this point.
Finally, assuming that we moved all the filesystems from vg2 to vg1, we can optionally remove vg2, recover its storage, and grow vg1. See Figure 4.
| Figure 1 | Figure 2 | Figure 3 | Figure 4 |
|
|
|
|
There are, of course, additional steps beyond what is shown above. (The devil is in the details.)
The table below compares differences in my Laptop and Server example configurations. Some of these can be mixed and matched; for example you could conceivably have a machine that follows the "laptop" configuration but uses a pair of disks as a RAID-1 array.
Similarly, you might decide that its acceptable to require human intervention in order to boot a server (your web server, for example, might have password protected SSL certificates, and so already requires human intervention). In that case, you could configure your server to require the LUKS passphrase to be manually entered at boot time (which is much more secure than the alternative).
| Variation | Laptop Example | Server Example |
| What is Encrypted? |
(Almost) Everything In this variation, everything on the system is encrypted, except for a small /boot partition that is used to bootstrap the system, and which contains no sensitive information. If the machine is compromised, an attacker can determine that you run a particular flavour of Linux, but that's about it. |
Sensitive Filesystems In this variation, everything is encrypted except for the following filesystems:
Because there is usually some amount of sensitive information in the /etc hierarchy, we also create a /crypted filesystem to which we can symlink such information. This gives a somewhat simpler setup and gives you the capability to at least boot into single user mode without having the encrypted data online, should there be a problem. (I've never actually seen such a situation, in practise.) |
| Underlying Disk |
Single Physical Disk This configuration is primarily suitable for laptops (or other machines) where you only have one hard disk. If you are using either SATA or SCSI disks, then if another disk is added to the system at a later time you need to be cautious about disk reordering. (This depends a lot on your BIOS. It should be fine for the addition of USB disks and similar devices after boot.) |
Software Raid This is the recommended configuration for servers and workstations. You gain not only redundancy (assuming an appropriate RAID level, that is), but the use of the md(8) devices isolates you from device reordering that can happen with SCSI and SATA disks. |
| Suspend & Hibernate |
Required In the configuration shown, suspend, hibernate, and resume are fully functional and the cryptographic integrity of the machine's state is retained through these states. Caveat: In grub, never change your kernel, kernel arguments, or other forms of configuration when powering up from a hibernated state! Therein lies the (potential) destruction of your data. (This warning is not specific to encrypted filesystems, but is applicable to hibernate operations in general.) |
Not Required In the configuration shown, we assume that we have no need to be able to perform suspend, hibernate, or resume operations. In particular, the method shown will not suffice for these operations. |
| LUKS Key Location |
Meatware (Manually Entered) This is by far the most secure way to store your keys, and is the recommended configuration for laptops. When your machine boots (or wakes up from suspend or hibernate mode) you will have to enter your LUKS passphrase. If you use this method for a server, it implies that booting will require human intervention. This is not practical for most data centers, but you must be the judge. |
Online With this method, the LUKS key is stored in an online location that can be accessed during the boot sequence. I document one such method, where the key is on a USB memory stick. This is not as secure as the meatware method, however it does allow the machine to boot unattended. Beware: Using such a mechanism is equivalent to not having encrypted disks in the sense that if an advesary gets ahold of the USB stick, they can also access all the unencrypted data on your disks. One case where this method may be of interest is when you consider your servers to be physically secure, but that you want to ensure that retired hard disks contain no recoverable sensitive information. (On the other hand, using a hammer until your hard disk platters rattle in a thousand pieces does wonders, with no run-time performance penalty ...) |
Feel free to experiment. Be prepared to throw out your first try and start again; your initial combination of variations might not be quite what you need.
Before you decide to implement these methods, you should examine your requirements. Do you really need disk encryption, or are you just doing it for the coolness factor? What are the trade-offs? In this section I describe a few factors that you should consider.
It's hard to say whether or not adding encryption to your system will have any significant impact on performance; it all depends on your workload. On my laptop, for example, there is no measurable (or noticable) difference in normal operations, although doing significant amounts of I/O can cause it to be noticable.
I ran some MySQL-based benchmarking on a xen system that had the underlying disks encrypted by dom0. The impact of the encryption was less than a 1% performance reduction, however xen vs non-xen took a 50% hit (regardless of whether it was dom0 or domN).
I'd suggest that benchmarking is the only way to truly know whether or not encryption will affect your performance.
The methods described here are, to the best of my knowledge, fairly robust when it comes to a general purpose filesystem. However, you need to be aware of some limitations, especially if you are going to be running a production database or similar applications. (This is another strike against using these procedures on a server.)
In particular, the described configuration is not condusive to gauranteeing proper ACID behavior (at least as of late 2008).
If you're using the "server" sample configuration (leaving / and /usr unencrypted) I suspect that upgradability is a non-issue, as only the standard mechanisms are used.
If, on the other hand, you're using the "laptop" sample configuration, things are less clear.
This document describes a not-officially-blessed procedure for handling the "whole encrypted disk" issue (the official procedure, once released, is almost certain to be both more general and more complex). It looks like allowing for encrypted filesystems during installation may be in place for RHEL-5.4. I can't say yet whether or not this procedure is expected to be compatible with RHEL-5.4. UPDATE: Please see the comments at the top of this page for 5.4 and later.
In an earlier version of this document, I mentioned that I expected trouble
when upgrading from CentOS 5.1 to 5.2. As it turns out, performing an upgrade
via the usual yum update mechanism works just fine since the
booted kernel has the various encrypted devices unlocked.
(But follow the procedures in the distribution release notes!)
However I still
suspect that trying to perform an upgrade by booting from the installation
media would be problematic.
In short, there is none.
When examining the completed system, it is obvious (or at least it can easily be determined) that it holds encrypted data, even if your advesary doesn't know what that data is. Once the data is decrypted, it's obvious that all the data was retrieved. If you're concerned about this, you might want to consider a steganographic file system (but beware of the "rubber hose" effect).
Given that public knowledge of cryptography has historically lagged behind that known privately by governments, it's probably unreasonable to assume that your data is protected from the various national intelligence agencies. On the other hand, if they are your adversaries, you've got bigger problems; my concern is primarily aimed at the more common "someone stole my laptop with my client data on it" kind of issue.
And then there's Quantum Computing. What a headache to privacy that's going to be ...
Absolutely no warranty is provided on any of this information. While it works well for me, you should satisfy yourself that your system is working as expected before loading on any data that you care about. (See the section on "Testing", below.) If you break your system, you get to keep the pieces.
I suggest reading this entire document before you start anything. You'll be wielding a big stick; you should understand what is going on before you do it.
Note that in the instructions below it assumes that you will be installing to a whole disk (wiping anything else that was on the system). If this is not a vigin system, BACK UP YOUR DATA (and make sure you can read the data from the backup media, including from other machines).
These instructions are based on a system that was installed with SELinux disabled. If you decide to use SELinux you should test your system more than I describe here and (as usual with SELinux) watch your log files for things that are failing because of an unanticipated configuration. I'd be interested in the observations of anyone who decides to try this procedure with SELinux. (Postscript: Less so now that encryption is offered in CentOS/RHEL 5.4.)
The procedure does not require a second hard disk for installation, although it should be trivially modifyable to use one if it is available. However, watch out for the disk reordering issue mentioned below.
The documented procedure involves a lot of rebooting; some of these are necessary, whereas some are validation checks. While the latter may not be strictly necessary, they may identify problems before it is too late to fix them.
Note that when using SATA disks on a newer motherboard I've noticed that under some (undetermined) circumstances the disks can be reordered so that (for example) what used to be sdc is now sde. If your system reorders the disk with the encrypted root partition for whatever reason, this procedure will not work. However, I suspect that such reordering would not occur if your root partition resides on the same physical disk as your /boot partition. This is also not a concern if you're using software RAID.
|
Are you ready, then? Feel free to continue with:
|
The information in this document is based in part on the following:
|
Contact me @ gdr at gno.org |
Last Updated: 21 May 2014 |
|