2016-03-14
Encryption is used to protect confidentiality. But what role should it play within your operating systems for protecting file systems?
The answer often is, "it depends."
Physical Theft
A laptop or detachable media such as USB-connected external disks and thumbdrives could easily be stolen or lost. Especially with smaller objects, you may not know which happened. Did the USB memory stick fall out of my pocket to probably be crushed underfoot on the subway staircase?
If a laptop was stolen, maybe it was part of a complex plot precisely targeting the data stored there. Or maybe it was simply because a laptop can have a good resale value for its size and weight.
Regardless of why and how the object disappears, whole-disk encryption makes sense. Microsoft's BitLocker is one solution. You can't even boot the Windows operating system until you enter a passphrase.
That's overkill. I don't care if someone gets a copy of the operating system. There are millions of copies of it out there already. All I need to protect are my user files.
Protecting User Data
On a UNIX-family operating system, Jane User's data is stored in /home/jane. We can boot the operating system with /home an empty directory. Then when Jane logs in, PAM (or Pluggable Authentication Modules) rules use pam_mount, so to ask her for a passphrase that is used to derive an encryption key. The kernel loads that key into RAM as part of its LUKS or Linux Unified Key Setup mechanism.
Jane's home directory and all her files and subdirectories are stored in a separate file system. That file system is stored inside one very large file, and that file has been encrypted with AES-256-CBC.
If it's really Jane and she typed her encryption passphrase correctly, the kernel can access the encrypted file system image. The file system image on the disk stays encrypted. The kernel uses the dm-crypt module to decrypt and encrypt all I/O on that file system as it happens.
The kernel mounts the file system image as /home/jane and passes all I/O through dm-crypt module using the key specific to this one file system.
If you're doing this on a multi-user system, maybe on the server, then Joe logs in. PAM asks him for his passphrase, and the kernel loads a new key into LUKS. The kernel uses Joe's key for all I/O on the encrypted file system image it mounts as /home/joe.
When one of these users logs out, the kernel flushes all pending I/O. This makes their personal file system image an updated and entirely encrypted large file. Then it unmounts their home directory and overwrites the key stored in kernel memory. If they log back in immediately, they will have to provide that passphrase again.
Putting That Together
You learn how to do most of the needed pieces in Learning Tree's Linux server administration course.
PAM: You will need to use the pam_mount.so PAM module to get their passphrase to the kernel, we use PAM in some exercises in the course.
Automounting: You will also need to use automounting for the home directories, and we have an exercise on that.
Logical Volume Management: LVM will probably be the best way to manage the encrypted file system images on multi-user systems. The course has several LVM exercises.
LUKS and dm-crypt: We don't do encrypted file systems in the server administration course, but I have a how-to here.
This makes sense on a portable single-user system like a laptop. In that case, put /home/username on a dedicated partition or logical volume using all the available storage.
Simply back up your user data to external media and do a fresh installation. Tell the installer that you want to customize the storage, make /home an independent file system, and ask for it to be encrypted.
Create your user account, log in, so it mounts your home directory through LUKS and dm-crypt, and restore your data into the encrypted file system.
Is This Really Useful On Servers?
Not really.
That is unless you worry that someone is going to steal your server out of the rack in the data center, in which case you have a physical security problem to solve!
But it's cryptography! Why isn't it helpful?
This is a good illustration of how cryptography can be helpful, but it isn't a magical security salve that makes everything better.
Let's say we have users Jane and Joe set up as in the story above. Both are logged in, so directories jane and joe are both mounted under /home.
Yes, the data is encrypted in the two large file system images. But access to the tree of directories and files must go through the kernel, which is used dm-crypt with the corresponding keys. File system I/O is completely transparent, even to users with bad intentions.
Whole-disk or file system level encryption prevents physical theft from being data theft, but it does not do access control. File ownership and permissions are the only things keeping Joe and Jane from inappropriately accessing each other's data.
What Alternatives Exist?
Linux supports FUSE or Filesystem in User Space. FUSE would let Jane create and connect an encrypted file system for which she controls the keys, not the kernel.
A much simpler approach involves encryption through an application. Check back next time to learn how to do that!