What is the best partitioning/encryption layout for a desktop user?

Greetings!

As a new Linux user, I find the whole partitioning and encryption business in Linux is rather complicated. Of course, you can simply use a guided partitioner in OpenSUSE (or similar easy setups from other distributions) and just check the mark to encrypt the device, but this doesn’t do exactly what I want.

And what I want is (from most important to least):

  1. Full encryption of all my internal partitions/drives. From what I’ve read the only thing you can’t encrypt is efi partion. Is that correct?
  2. No need to enter a password separately for every encrypted partition.
  3. Ability to suspend to disk.
  4. Flexibility to expand/shrink encrypted partition if necessary. And to add new encrypted internal drives without the need to enter separate password for them on boot.
  5. Easy reinstall.

Some layouts I consider:

  1. Single encrypted BTRFS partition, no lvm

From my research, I think a single btrfs root partition without a separate home must be what I want. It is flexible - you don’t need to preallocate space for root and home. And I believe, it is easy to reinstall - if you reinstall the system the installer should recognize @home subvolume and not destroy/overwrite it, but mount it as a new home, at least if you use btrfs on your new installation too. Correct?

It will be nice to have everything including swap on one btrfs partition. Cause if you have swap on a separate partition then you have to encrypt it separately, and use a separate password to unlock it, right? (I am aware that of lvm, but we don’t use it in this layout).

It is easy to create a swap partition in installer, but is it possible and how to create a working btrfs swap subvolume? And can we then use it to suspend to disk?

From what I understand you can expand a btrfs partition and add new drives in it. But since we have an encrypted btrfs partion, in another words a partion in an encrypted LUKS container, we can’t expand it or add new drives in it it, because we cannot expand a luks container, unless it is inside an lvm, am I correct?

So, if we add new drives that we want to encrypt in this layout, we have to encrypt them separately, and enter separate passwords for them on boot, right?

  1. Single encrypted LVM partition.

Say now we have a btrfs partion like previously, but inside an encrypted LVM.

Now we don’t have to worry about separate swap a partition, because it is inside an encrypted LVM anyway.

On the other hand I’ve read that LVM makes data recovery from LUKS encrypted partitions much more difficult. And we still can’t expand it, because it is encrypted, right?

Also, with btrfs, LVM feels redundant, because btrfs has all the features of LVM, such as flexible partioning, snapshots, etc.

  1. LUKS on LVM. Volume group with multiple LVs, that have luks encrypted partitions inside them.

For example we have an LV that contains encrypted root partion, and we can have an LV for another drive. That way we can expand our LVs and encrypted partions they contain, but we still need to have separate passwords for other drives, if I understand correctly. And this whole setup is quite complicated.


Possible solution for entering password multiple times with multiple partitions:

Since we have boot partition encrypted we have 2 enter password at least twice on boot. There is a way to avoid that, as described here, but according to this statement in this thread:

The disadvantage: you now have an encryption key in a file in the root file system. And you also have it in the “initrd”. The more copies, the more likely that it will leak. However, the file in the root file system is readable only by root, and the “initrd” is readable only by root. So some folk think this is a reasonable approach.

If you later install Xen support on a UEFI machine, the “initrd” will be copied to the EFI partition. And that make it readable by anyone with sufficient access to your machine. So the encryption key has been made more readily accessible, which is risky.

It comes with security compromise. And entering the password twice is fine by me then.

But if we have more than 1 encrypted partition we would have to type password more for every additional partition we have. It seems one (and only?) way to avoid this is to create a keyfile somewhere in the root partition and configure cryptab and fstab to automatically use it to decrypt other partitions after the root partition is decrypted. **It seems it doesn’t come with all security compromises of decrypting the root with keyfile, because for non-root partitions, we don’t add keyfiles to initframs. Is that correct?
**

In overall, does what I wrote here makes sense? What partitioning and encryption layout can you suggest given my requirements? Something I described above or something else? If you use encryption yourself, how do you paritition you drives?

Linux is UNIX® – The traditional way to implement things was “Do one thing and, do it well.” – Sadly, things have got more complicated because, the modern systems are more complicated … >:)

Encryption –

  • Yes, if you have a portable device such as a Laptop, encryption of your user data is advisable for travellers …
  • If it’s really a Desktop system located in an office then, encryption is possibly an overkill – assuming that, no unauthorised persons have access to the office …

Taking the points one by one –

  • Why do the system partitions need to be encrypted?
    *=2]The user login passwords are either located (encrypted) on a server in a secure computer room or, they’re located in the local encrypted “shadow” file.
    *=2]Yes, a proficient intruder with a powerful machine can crack the passwords if they can gain physical access to the system partition – the question is, can the intruder gain physical access to the Desktop machine?
  • If you encrypt the EFI partition, the Mainboard’s UEFI/BIOS will have a problem to boot the system – maybe, there will be Mainboards with a UEFI/BIOS which can handle an encrypted ESP but, nobody seems to know when and/or, if that will ever be needed …
  • Whatever you do, at boot time you’ll have to enter the password of an encrypted system partition – as additional encrypted partitions are mounted, the password either needs to be entered by the “booting person” or, the key has to be obtained from a secure server – see “cryptctl” – <https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-cryptofs.html&gt; – “cryptctl” – <https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-configure-cryptctl.html&gt;.
  • There doesn’t seem to be a local “key wallet” for system processes available, which can provide the keys for each encrypted partition at boot time – there are however user wallets – suck as the KDE KWallet and the GNOME Keyring – which can supply the keys for mounts performed by a “normal” (human) user …
  • The current Linux Kernels do not support hibernation – “suspend to disk” – because of, an encryption security issue which hasn’t, to date, been resolved …
  • Expanding/Shrinking of encrypted partitions can only be done by means of a “Live” system disk – such as the “repair” facility on the installation DVD …
  • Exactly what do you mean by “easy re-install”?
    *=2]If the system with the encrypted partitions “dies” then, the encrypted files are lost – for ever …
    *=2]Encrypting partitions means, regular backups to external (not encrypted) media which can be stored at a secure location …

I can’t give advice. You will have to decide that for yourself. But I will describe what I do and have done in the past.

If you encrypt several partitions that are all mounted during boot, then you normally only need to give one encryption key (assuming that they all use the same key). I’m not sure if this is due to “plymouth” or to “dracut” – probably both. They use the first key that you enter and try it for other partitions before prompting.

However, if “/boot” is encrypted (or part of an encrypted partition), then you will need to enter the encryption key an additional time for “grub2” to use – note that there are workarounds for this.

My first experience with crypto: I encrypted “/home” and swap. I did not encrypt “/” as that did not seem so important. For swap, I set it up to use a random encryption key – the effect of that is that hibernation (suspend to disk) is not possible.

I later switched to encypting “/”, and “/home” and swap, all using the same luks encryption key. When doing this, I used a separate unencrypted “/boot” that way, I didn’t need to give the key for grub2 booting. And note that I have been using “ext4” for the root file system. I use a separate “/home” because my preference is to do a clean install of the next version while preserving “/home”.

Currently, I am using an encrypted LVM, and I have volumes for root, home and system within the LVM. This seems to be a better layout (in my opinion), so I have been doing it this way for several years. Note that the entire LVM is encrypted, so that the volumes inside the LVM do not need to be separately encrypted. I am still using a separate unencrypted “/boot” on most systems.

I do actually have two systems without a separate “/boot”. So, for those, I need to enter the encryption key twice – once for grub2 and once for the kernel. I agree with your reasoning, that it is wiser to do this than to risk weakening the security.

I also have one system with an encrypted LVM, no separate “/boot” and using the workaround to avoid entering the encryption key twice. This is in a KVM virtual machine, and is mostly so that I can test and experiment with that workaround.

As for “btrfs” – I have experimented with it. And I don’t have any principled objection. But “ext4” seems to be working well for me, so I’ll stay with that for now.

Thank you for the answers!

Does this implies that for a laptop computer (not server) there is no way around entering password manually for each encrypted partition? I though you can create keyfiles, put them somhere in root partition, and configure crypttab and fstab, so that other partitions are automatically mounted and decrypted, after you entered the password for root?

On archwiki they suggest encryption setups such as LVM on LUKS, that should support suspension to disk. Is that a recent problem with current Linux kernels?

I mean that if you reinstall Linux, user’s data in the home folder are preserved during reinstallation.


This is good news. Simplifies things a lot. I though that even if the passsword is the same I still have to enter it manually for each partition.

I am aware of the workaround. But entering password 2 times, I think is not a big deal yet.

In another thread you wrote about one disatvantage of this workaround:

If you later install Xen support on a UEFI machine, the “initrd” will be copied to the EFI partition. And that make it readable by anyone with sufficient access to your machine. So the encryption key has been made more readily accessible, which is risky.

Does this applies also if we configure decryption of non-root partition with a keyfile to save typing password an additional time, for example as described in archwiki here? (the exact section I linked). I guess not, but I’d like to know your opinion.

But in theory if you encrypted swap with LUKS with the same password, then you wouldn’t have to enter password separately for swap, because it tries it for all partitions, right? And then hibernation will be possible?

It seems you did exactly that. Is hibernation possible in this setup?

And what will you do if you want to add another drive to your machine? Create a separate encrypted LVM for that drive using the same password?

Yes, you can do that. It seems reasonably secure.

On my main desktop, I have an encrypted “/shared”. But I use the same encryption key as for the root file system (really, for the encrypted LVM), and it is automatically unlocked at boot.

On archwiki they suggest encryption setups such as LVM on LUKS, that should support suspension to disk. Is that a recent problem with current Linux kernels?

As far as I know, that works. I rarely use hibernation, so I haven’t tested this well. And I’m not quite sure what “kernel lockdown” does (only applies with secure-boot enabled), but I think that still allows hibernation if you are using encrypted swap.

This is good news. Simplifies things a lot. I though that even if the passsword is the same I still have to enter it manually for each partition.

It seems that both “plymouth” and “dracut” try to remember the password already used. But once the boot has proceeded beyond the point where “dracut” and “plymouth” are involved, you might need to enter again for a new partition being mounted.

Does this applies also if we configure decryption of non-root partition with a keyfile to save typing password an additional time, for example as described in archwiki here? (the exact section I linked). I guess not, but I’d like to know your opinion.

I don’t see a problem with doing that.

But in theory if you encrypted swap with LUKS with the same password, then you wouldn’t have to enter password separately for swap, because it tries it for all partitions, right? And then hibernation will be possible?

Right. But I did not know that when I first tried encryption.

It seems you did exactly that. Is hibernation possible in this setup?

It seems to be. I don’t use it much, but it has worked when I have tested it.

And what will you do if you want to add another drive to your machine? Create a separate encrypted LVM for that drive using the same password?

I actually have a second desktop machine with two drives. I have an encrypted LVM on each drive. And they use the same password.

I use the same “/etc/crypttab” on all installed systems, except that I comment out the entries that I don’t plan to use. On one installed system there, I leave all “/etc/crypttab” entries uncommented. And they are properly mapped on boot. I can see that by looking at “/dev/mapper”. And running “grub2-mkconfig” successfully finds the systems in each LVM to add to the grub menu. So this can work quite well.

So in this setup you enter a password only once to decrypt both drives, correct?

From my research, I think a single btrfs root partition without a separate home must be what I want. It is flexible - you don’t need to preallocate space for root and home. And I believe, it is easy to reinstall - if you reinstall the system the installer should recognize @home subvolume and not destroy/overwrite it, but mount it as a new home, at least if you use btrfs on your new installation too. Correct?

This is NOT correct. But you should have a backup of home in any case.

Correct – and now some noise to meet the minimum reply length for forum software.

I skipped over this on my first reading. Then I noticed the reply by doscott. I want to agree with doscott on this.

I have actually tried this (re-using “btrfs”) and the installer wants to reformat it with preserving any subvolumes. This is one of the reasons that I still recommend a completely separate “/home”.

Ok, good to know. I think I saw somewhere on the internet said that in his btrfs setup, /home was preserved after reinstall. But it was some different distribution. Maybe the potential to do it is there with btrfs, just installer don’t realize it?

And thanks for your answers. Really helpful!

I am an enemy of btrfs.

Some eight years ago it gave me a bad crash.

A few years ago I discovered that a partition was formatted btrfs without being noticed. The computer was slow when working with that partition.

Recently I discovered that some btrfs-related installed packages in opensuse slow down the shutdown of the computer. It was not easy to discover. Btrfs was not used in the computer, but the software was needed for utilities like gparted.

Now I avoid anything “btrfs” like a plague. They couldn’t make it reliable. The old ext4 wins by huge margins in reliability.

I won’t go that far.

I’m still using “ext4”, and that has been working well for me. I do occasionally experiment with “btrfs”, and it has been reliable enough. Yes, at times “btrfs” seems slower, but probably not by enough to really matter.

For now, it is still “ext4”. Perhaps I will change my mind on that in the future.

Personally, I doubt that –

  • Yes, “Copy on Write” is currently fashionable – for how long? – Don’t know …
  • Snapshots – wonderful – for common human behaviour – but, you can’t beat a backup …
  • Snapshots – file versioning is better «for dealing with common human behaviour» – bring back DEC’s file systems … >:)
  • Snapshots – for system directories – yes, there are Use Cases but, I’m not really a fan of this approach – except for the system Use Cases where it makes sense – »I’ll have to think about the possible Use Cases – can’t think of any right now … «

ZFS is available with openSUSE.