2

Goal: (mostly) full disk encryption with several volumes, some independently encrypted

Rationale: Encryption will secure a disk that is not booted, but for a system that is on 24/7 it does not offer much security while in place. Also, it would be desirable to keep certain data unmounted and secured when not needed even from an authorized user.

Possible solutions:

Multiple LUKS on LVM

  • Drawback: Should work, but generally ill-advised and complicated.

LVM on LUKS + separate partition with LVM on LUKS

  • Drawback: Having a partition reduces the benefit of LVM flexibility.

LVM on LUKS with some volumes as LVM-on-LUKS-on-LVM-on-LUKS, i.e. double encryption

  • Drawback: Possible performance hit of double encryption. Also, complicated/convoluted. But maintains flexibility of LVM.

Which if any of these options might be best?

How much of a performance penalty would be caused by double encryption? hdparm -t showed effectively no difference in disk reads on my SATA SSD between unencrypted, encrypted, or double-encrypted volumes.

Any other solutions?

Improve this question
7
  • 1
    As you stated, disk encryption protects the data while the LUKS container is locked. Once unlocked it is up to the operating system's access controls to protect the data stored in the filesystem. What is it that you're trying to achieve by using multiple layers of LUKS?
    – Emmanuel Rosa
    Jun 27, 2018 at 2:12
  • @EmmanuelRosa I would like to keep certain types of data, for example financial records, always encrypted and unmounted, and accessed only when necessary.
    – adatum
    Jun 27, 2018 at 3:53
  • What is the risk you're trying to mitigate? The issue I see is that once you unlock and mount the filesystem containing the private data, said data is available as if it were not encrypted in the first place. In other words, merely accessing the data as necessary puts it at risk during the time it is being accessed.
    – Emmanuel Rosa
    Jun 27, 2018 at 20:18
  • @EmmanuelRosa Precisely. Thus, to minimize risk, it makes sense to minimize the time during which the data is accessible. In any case, for now I've decided to keep the flexibility benefit of LVM on LUKS, and just add logical volumes or (double) encrypted volumes as needed on top of it. For performance considerations, I'll be mindful of how sensitive given files are and minimize what goes into a double encrypted volume. In principle I would prefer to keep most things encrypted/unmounted and unlock/mount only on a need-to-access basis.
    – adatum
    Jun 27, 2018 at 21:29
  • Have you looked into accessing the sensitive data within a Linux container? The container's root filesystem can be stored in an encrypted block device (or file treated as a block device). For instance, say you want minimize the risk for GNUcash files, theoretically you may write a script to unlock the block device, run GNUcash using a Linux container with the unlocked device as the root filesystem, and upon termination lock the block device.
    – Emmanuel Rosa
    Jun 28, 2018 at 17:25

1 Answer 1

Reset to default
2

Difficult to answer since mostly opinion based. You might as well ask which is better, LVM on LUKS or LUKS on LVM. Either way works and might suit your particular requirements better.

For independent LUKS containers, LVM -> LUKS certainly sounds more interesting than LUKS -> LVM, at the cost of having LVM metadata unencrypted - and Logical Volume names, sizes, creation times, etc. might be revealing.

Double encryption certainly involves a performance penalty (even with AES-NI). However that's still fine in some use cases. Maybe your CPU is very idle (not uncommon on overpowered desktop systems) so you don't notice any difference, or maybe your double encrypted data is otherwise just not performance critical.

I'd probably end up doing that, I already have LUKS -> LVM so if I needed another encryption layer, it would be LUKS -> LVM -> LUKS simply because that's easier and safer to do (just make another LV and put LUKS on it) than say, shrinking a PV to make room for an independent LUKS partition (things can go wrong when pulling stunts like these).

However, I'd not put another LVM layer onto that since I don't quite see the point of LVM inside LVM. So LUKS -> LVM -> LUKS is the end of it, for me.

In theory, it would be possible to do the double-encryption setup without double-encryption, i.e. the device mapper could allow the inner LUKS container to pass its data to the outer device directly without encrypting it twice. The device mapper should be powerful enough to make this happen, but LVM and cryptsetup almost certainly won't support such things.

Improve this answer
1
  • How can the performance of LUKS on LVM on LUKS be measured? Good point about not needing another LVM on top of that. Avoiding double encryption while keeping separate LUKS containers would be awesome if it could be made simple/automatic. I was advised against using LUKS on LVM for reasons I've forgotten.. and having unencrypted metadata is also unappealing. Also, could you clarify the meaning of your arrow (->) notation?
    – adatum
    Jun 26, 2018 at 20:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .