Linux – Which partitions should I encrypt

arch linuxencryptionluks

My laptop is currently running Windows and Fedora, but I'm planning to install Arch Linux as my sole OS soon. This current setup is using whole disk encryption through TrueCrypt, but I'm unsure if it might be unnessesary for me.

I think I'll be using a somewhat simple partition sceme, something like: /, /boot, /home and swap.

I'm using my laptop for average everyday PC usage, programming, testing on local web server or on a virtual web server, audio/video playback, audio editing/recording etc.

I want to encrypt my next Arch only setup as well, but I can't decide whether to partition the whole disk, just the home partition or something else. I want to encrypt the system mainly for securing eventual lost/stolen data.

I'm thinking that dm-crypt with LUKS would be my best choice, but I'm not sure.

What should I choose and why?

Best Answer

In most scenarios, one of the following three schemes works well.

You only want to encrypt a few particularly confidential files.

Use encfs:

mkdir ~/.encrypted.d ~/encrypted
encfs ~/.encrypted.d ~/encrypted
editor ~/encrypted/confidential-file

Pros: no overhead to access non-confidential files; you can have different hierarchies with different passwords; you can easily copy a whole hierarchy of encrypted files to another machine; you don't need any special permissions to use encfs.

Cons: only encrypts files that are explicitly placed in the encrypted area; a little slower than disk-level encryption if you're going to encrypt a lot of files anyway.

You want your whole home directory to be encrypted.

Use ecryptfs.

Pros and cons. In a nutshell, ecryptfs works especially well when you want to encrypt your home directory using your login password; this is what Ubuntu uses if you tell the installer to encrypt your home directory. One con is that it's more difficult to ssh into your account, because if you're using key authentication for ssh, your public key must be placed outside the encrypted area and you'll need to type your password after ssh'ing in.

Whole disk encryption.

Use dm-crypt to encrypt everything except /boot.

Pros: everything is encrypted, so you don't have to worry about accidentally putting a file in the wrong place; block-level encryption provides better speed, especially if your processor has a hardware accelerator for AES (AES-NI on x86).

Cons: you need to provide the password at boot time, so you can't do an unattended boot; everything is encrypted, which can be slow if your processor is slow.

General notes

If you don't go for full disk encryption, remember that some temporary copies of your data may end up outside your home directory. The most obvious example is swap space, so if you're going to use encryption to prevent from a thief from reading your data, make sure to encrypt it (with dm-crypt). Since swap space is reinitialized at each boot, you can use a random key for it, and this way you can do an unattended boot (however, this makes hibernation impossible).

Put /tmp under tmpfs (it's a good idea anyway). See How to (safely) move /tmp to a different volume? for how to migrate /tmp to tmpfs.

Other at-risk areas are the mail drop (/var/mail) and the print spooler (/var/spool/cups).

Related Solutions

How to get a usable full disk encryption with different encryptions for different users

Don't encrypt the whole hard drive (as in /dev/sda, do it per partition (or more precisely per file system - see below).
Have separate file systems mounted at homes for the two users. I'm intentionally avoiding writing separate partitions, since while that is the usual way of doing things, it is constraining in some aspects. It might be more convenient to have one large home partition, which holds big files that contain the encrypted file systems and are mounted as necessary. The advantage is easier resizing of users' homes while keeping them separated.
Automounts on login are possible through PAM. Note that you don't want to use the same password for login and for the actual data encryption. Instead, you either use LUKS or imitate it by storing the encryption key in a file that itself is encrypted with the login password. That ensures that a change of the login password won't affect the encrypted data but only the encrypted key and thus yo won't have to take care of re-encrypting whole users home).

General instructions:

partitioning use gdisk (also known as gptfdisk sometimes), parted or any other appropriate program, read man pages for details (partitioning is a bit out of scope of this QA)
encrypted file-based file systems - I have some objections to the design of LUKS, so I'm generally using cryptsetup in the "plain" mode, which imitates LUKS in some aspects. If you choose LUKS, than you can just reduce the steps to the cryptsetup (with appropriately modified options)
1. prepare the encryption key and password. This is an interesting part - for encrypting the data you want something with enough randomness (8 letter password really isn't enough) and for password something that you can change easily (without needing to re-encrypt the whole filesystem) and is reasonably easy to remember and type in. These requirements go quite against each other. Hence we'll use the same trick that LUKS does (and which can actually be considered a variation of a hybrid cryptosystem in some sense)). The encryption key can be more or less random - either use some really random data (e.g. from /dev/random), or a reasonably long hash like SHA-2 or SHA-3 (the first one was designed by NSA, if you wonder whether to use it or not in light of the recent events) of a reasonably long passphrase.
  
  Reasonably long in the first case (and in the case of really random data) means, that the length should be about the chosen key length for the cipher used plus the length of the initialization vector. In the second case it means that it should be difficult to brute-force it. Using a hash has the advantage of being able to recover the key if it gets damaged or lost (provided you remember the initial passphrase that was hashed, of course). This key is then encrypted and stored in a file. The passphrase for the encrypted key in your case will be the same ass the login password.
```
# set up the encrypted encryption key
printf "Reasonably long and complicated passphrase" \
    | openssl dgst -sha512 -binary \
    | openssl enc -bf > /path/to/key.enc
```
  openssl dgst -sha512 -binary produces binary form of the SHA-512 hash from its standard input, openssl enc -bf encrypts it using Blowfish - feel free to choose hash and cipher to your liking (Twofish or Rijndael are both rather well-tried, but other ciphers available in the kernel should be fine too).
  
  Keeping the key outside of the encrypted device has a disadvantage of needing additional thing apart from the encrypted data itself - LUKS stores the key in its headers, so it's self-contained. On the other hand you are bound to a particular set of tools. While it is not designed carelessly and is present on most installations, you need the special tools to access it.
  
  With a separate file on the other hand, you are free to choose any method of storing the key. You can even put it on removable media, insert it before login and remove it once the file system is mounted (you could probably even hook automatic login on the event of attaching the media to the computer). Of course all this should be well thought through since the security maxim "Do not invent your own crypto" applies (see e.g. this post on Security SE) - which might actually be an argument for using LUKS. Backing up the key is obviously easy.
2. create an empty file that will hold the file system
```
dd if=/dev/zero of=/path/to/backing_file.enc bs=1M count=X
```
3. create the encrypted device
```
openssl enc -bf -d -in /path/to/key.enc 2>/dev/null \
    | cryptsetup create \
            -c twofish-cbc-essiv:sha256 \
            -s 256 \
            -h plain \
            encryptedfs /path/to/backing_file.enc
```
  openssl enc -bf -d asks for password on stdin and tries to decrypt the encryption key. cryptsetup create ... encryptedfs /path/to/backing_file.enc created encrypted DM device called encryptedfs backed by the previously created file. Important option it the -c which selects the encryption cipher and its mode of operation
4. fill the device with zeros - this effectively puts "random garbage" into the backing file and makes it less obvious, what the contents of the file might be (otherwise, you could tell where things have been written by scanning for blocks that are not zeroed from step 2).
```
dd if=/dev/zero of=/dev/mapper/encryptedfs bs=1M
```
5. Create a filesystem
```
mkfs.[favourite_filesystem] [tuning options] /dev/mapper/encryptedfs
```
6. Put a corresponding line into /etc/fstab in case you want to do everything on your own, or into /etc/crypttab if you want some sort of integration with system tools.
for automatic (un)mounting on login/logout, I'll refer you to the pam_mount documentation.

Linux – NixOS installation on multi-boot system with GRUB (from Arch installation)

With the help above from Alexander Batischev, and some very useful information from Reddit user cookie_enthusiast on the /r/linuxquestions page on Reddit, I managed to get this working.

It turns out that GRUB2 works well with UUIDs, and not so well with device names. With this knowledge in mind, we need the following 4 UUIDs at hand, before we can (manually) create an extra GRUB menuentry to our NixOS grub.cfg configfile:

The UUID of the LUKS device.
The UUID of the LVM Volume Group.
The UUID of the LVM Logical Volume.
The UUID of the filesystem containing the grub.cfg file we want to load via the configfile directive in GRUB2.

I will list here how to obtain these four UUIDs:

Execute cryptsetup luksUUID /dev/sda2 and remove all the dashes (-) from the UUID, a0cb535a-8468-485f-a220-a5f49e85c9f4 would become a0cb535a8468485fa220a5f49e85c9f4 in my case.
Execute vgdisplay and look for the VG UUID, lvmpool with UUID 5atKN9-PQBi-T9wb-Iyz8-qP4y-HN2E-c5uLOT in my case.
Execute lvdisplay and look for the LV UUID of the LV Name or LV Path that contains your grub.cfg file, nix-root or /dev/lvmpool/nix-root with UUID C9zkjF-IHu0-qQkP-KgLf-8rAy-TVPu-HQ7gtj in my case.
Execute lsblk -p -o +UUID and look for the UUID of the Device Path that contains your grub.cfg file, /dev/mapper/lvmpool-nix--root with UUID cc6a06bb-336f-4e9f-a5f0-fdd43e7f548f in my case.

This will allow you to create the following extra GRUB menuentry for referencing our NixOS grub.cfg configfile, which is on my nix-root lv and because of the boot.loader.grub.device = "nodev"; in my /etc/nixos/configuration.nix there is no GRUB installed for my NixOS installation (in Arch, this would go into /etc/grub.d/40_custom):

menuentry 'NixOS' {
    insmod crypto
    insmod cryptodisk
    insmod luks
    insmod lvm
    cryptomount -u a0cb535a8468485fa220a5f49e85c9f4
    set root='lvmid/5atKN9-PQBi-T9wb-Iyz8-qP4y-HN2E-c5uLOT/C9zkjF-IHu0-qQkP-KgLf-8rAy-TVPu-HQ7gtj'
    search --fs-uuid --set=root cc6a06bb-336f-4e9f-a5f0-fdd43e7f548f
    configfile '/boot/grub/grub.cfg'
}

To clarify this even more, this contains some literal values such as lvmid which is not supposed to be replaced with the name or ID of your LVM. This is not properly documented anywhere, it seems. The same issue applies for when your put the UUID of your LUKS device in the cryptomount -u line with dashes in it, GRUB will just tell you Press any key to continue, which is (obviously) not very helpful.

The bare template for a manual GRUB menuentry to boot from crypt -> LVM -> root with an LVM on LUKS setup would thus be:

menuentry 'NixOS' {
    insmod crypto
    insmod cryptodisk
    insmod luks
    insmod lvm
    cryptomount -u <LUKS UUID without dashes>
    set root='lvmid/<LVM Volume Group UUID>/<LVM Logical Volume UUID>'
    search --fs-uuid --set=root <Filesystem UUID>
    configfile '/boot/grub/grub.cfg'
}

For those who are interested in the other half also, I modified my /etc/nixos/configuration.nix file to look like this:

boot.loader.grub.enable = true;
boot.loader.grub.version = 2;
boot.loader.grub.device = "nodev";
boot.initrd.luks.devices = [ { name = "cryptroot"; device = "/dev/sda2"; preLVM = true; } ];