Question about the order of FDE steps with LUKS and LVM
Question about the order of FDE steps with LUKS and LVM
I'm setting up FDE and wonders which one is better. "LVM over LUKS" or "LUKS over LVM"? Or something else? Does one is definitely better then the other? What are your preference?
Thanks.
You're viewing a single thread.
It depends where you want your encryption. If you want all of your LVM volumes to be encrypted at once then you want LVM over LUKS. If you want volumes with different encryption, or no encryption, then you want LUKS over LVM. You can also do LUKS over LVM over LUKS if you must but that's kinda dumb.
LVM over LUKS is more common as generally people want to encrypt everything.
I use ZFS native encryption, so I guess that's closer to LUKS over LVM for personal preference.
Should the LVM partition layout considered as metadata leak in LUKS over LVM?
Yes
Should I worried about it?
Probably not. The metadata it leaks will be the name of the volumes, their sizes and possibly used space on them.
It really depends on your use case. If you're only using one key, I'd put LVM on top of LUKS just for the simplicity. Otherwise it becomes a threat model analysis: if someone steals your computer or drive, do you care that they know you have 5 volumes on them and roughly how much data is on there?
I need my desktop to boot unattended, and it's got 5 drives in it, so it made sense for me to have separate encryption. It boots and does its NAS duties on its own, then when I log in a dedicated dataset gets mounted for me with all my data on it. From there I might unlock some volumes for work by getting their key from an AWS Secrets Manager endpoint. My laptop is plain f2fs over LUKS.
I'm planning FDE on my laptop which have 2 drives. I originally plan to use LUKS on LVM as I can use LVM to join two drives into one. But now I wonders if my choice is right.
That works too, if you have a use case go for it. There's so many valid ways to arrange your disks.
LUKS over LVM over 2 disks is as valid as LVM over 2x LUKS which is as valid as LVM over LUKS over RAID1. Although with multiple disks I'd probably go with filesystem mirroring with btrfs or ZFS, and give it the two LUKS volumes. That way you get per file chunk checksums and self healing if your drives start to drift off (RAID won't tell you if either disk returns garbage, and has no way of telling which disk has the correct data).
But really, I wouldn't worry about LVM metadata unless you're holding some seriously sensitive and valuable data. I can't think of a use case where LVM metadata would be bad but not LUKS headers. Like the only information really leaking is the name of the volume and how big it is, so unless you happen to have a dedicated volume full of secret documents of a known size and that can be used as evidence of you being in possession based on the size alone, it's kinda eh.
So you mean BTRFS over LUKS? I will have a try on a VM later, plus the ZFS too. Thanks for the advice.
From the info I've gathered, it seems that LUKS over LVM is the "proper" way as ideally you'd only want to encrypt swap, /tmp and /var. (/tmp and /var are places for temporary files, ie. opening a .zip archive. Swap is just RAM on your hard drive, so a place where your passwords could be stored) Encrypting the root (equivalent of "program files" in Windows) won't make your system more secure, just slower. (If you live in a place where you need to keep the list of your installed apps private, you'd probably be fricced by using encryption anyways.) Home directory should obviously be encrypted ~~but for the best performance you should use file level encryption instead of block level. ~~ edit: Do your own research on the performance, a reply claims otherwise, though leaving root partition unencrypted obviously increases R/W speed.
The thing is that setting it up this way is pretty hard so distros generally use 2 easier methods to setup encryption. Either encrypt the whole disk (LVM over LUKS) or encrypt only the home directory. I wonder whether the latter is secure enough though. Mint for example does not explicitly state that swap, /var and /tmp are encrypted when you select "encrypt home directory" but on Cinnamon there is not hibernation option so there is a chance that Swap is encrypted, just with a one-time password, which gets generated on boot and deleted after shutdown. <--- citation needed...edit: I've just tried hibernating in Mint without FDE and it didn't work, you just get a new session after resuming, so that's good.
Relevant article: https://www.linuxinsider.com/story/the-case-against-full-disk-encryption-86774.html
I though FDE is to thwart physical access to exfiltrate and or recover data. Making the root partition unencrypted surely will boost performance but I feel like this opens up an additional avenue for an attacker to exploit and defeat the purpose of doing FDE? It isn't just making "installed apps private" but literally replace some binaries with a backdoored version of it with then enables access to decrypted data.
If an attacker has physical access to your device, you should not use the device afterwards, ever. There are some mitigations like Secure Boot and Heads OS, but they only slow down the attacker. Given enough time, you cannot stop him. Heads OS is pretty much for giving your laptop to airport security temporary and Secure Boot has been hacked in a minute. Although that was using TMP outside of the CPU, I would not trust Secure Boot with TMP 2.0 for anything other than a quick customs check either.
Using FDE as a protection against physical attacks is just a false sense of security. Veracrypt for example go as far as to say that secure boot is false sense of security.
For maximum paranoia there is a use for FDE, though. If you install a crappy app that saves data outside of RAM, /home, /var and /tmp, the data won't get leaked. Though that would be a massive security issue because most linux computers are servers which cannot use FDE.
For secure boot bypasses I could only find BlackLotus is the only one capable to do this. I would like to have more details to support the claim "Secure Boot has been hacked in a minute." Also, I would like the explanation on secure boot is a false sense of security and points to suport such claim as BlackLotus is the only publicly known malware to bypass secure boot.
However, I do firmly believe that there ia no reason that servers can't use FDE as they are no differ than other typical computer.
EDIT: forgot the "boot" for secure boot
The secure boot vulnerability was shown on a lenovo laptop. I've found https://www.welivesecurity.com/2022/04/19/when-secure-isnt-secure-uefi-vulnerabilities-lenovo-consumer-laptops/, but I'm not sure whether it's the same thing I was talking about. The attack abused the fact that the TPM chip was outside the CPU so it was possible to read the keys in plain text by just putting a clip on the chip. The laptops in the ESET article seem fairly new so I would expect them to have TPM inside the CPU.
I recommend reading "threat model" page on Heads OS' website. Secure boot can be disabled in the UEFI settings which can be accessed by unplugging the CMOS battery to reset the UEFI password. Undoing a few screws takes a few seconds so the bottleneck would be how fast you can upload your fake login screen onto the drive.
Servers can use FDE obviously but using them becomes highly inconvenient if you enable that. In order to boot you need to decrypt the drive but how are going to connect to the server if it hasn't booted yet? One solution is to only boot the server when you have local access. The issue rises when your server crashes. Alternatively you can either start sshd early in the boot process at which point it isn't really FDE or have some kind of KVM which just shifts the issue to a different device.
I think people tend to get hung up on where you store the key material for a server. Hardware token and TPM being two options that are less secure, but network bound disk encryption is supported as well as a combination. So you could have it require the network key as well as the matching PCRs from the TPM for the proper software load before it will unseal.
Hardware token being less secure?
If I steal the server I have the token, unless someone is physically going to unlock the server every time you reboot which is not realistic.
TPM has been bypassed. Researches found a lot of laptops where you can just attach wires to the TPM communication lines and you can just listen and wait for the TPM to spit out the key.
It's a hardware attack so game over. But still worth doing especially on servers and desktops because then it's still much more of a skilled attack than someone just stealing the drives. Especially servers with their front drive bays you can literally just pop the drive. And if the drive dies and you can't erase it, it's fine, you can throw it away and not care because it's FDE so you can just throw away the keys.
The most common physical attacks will be you misplacing your device or some friend/burglar/cop taking it. FDE works great in those scenarios.
Not really, rewriting the boot sector with your malware can be scripted so even the average burglar could use it. Using a previously stolen laptop without reflashing the firmware or something similar isn't worth the risk imo.
If you're not careful
/etccan also contain passwords and other sensitive files. My WiFi password is there for example because it needs to be in the wpa_supplicant config file. On servers that's TLS certificates and keys.In my experience block level is faster, and less of a hassle, and can support hibernation properly. Also much easier if you want just one big partition to not waste space on separate root home and var.
Thanks for the correction. I would also like to add that /root is probably also something that should be encrypted, you won't have to shred your root account's bash_history after accidentally typing your password into the root shell.
I didn't clarify this in the original comment but imo unless your distro specifically offers the option to partition a drive the way I described it, it's not worth it. (as far as I know, no distro offers this kind of encryption)