Summary: I’m looking at Linux FDE options that are transparent to the user (my parents) in that the user doesn’t need to enter 2 passwords. I am stating each option I found/thought of and then what I think the security implications of each are. Wanting to see if anything is inaccurate/missing. This got a bit longer than I intended… sorry about that but I don’t see any obvious stuff I could cut out. Tried to add formatting/etc to make it more readable though.
Now that my previous mistaken concerns that LUKS was vulnerable have been addressed and my (mis-)understanding corrected, I am continuing to look into using it for a Linux FDE /home partition setup. For myself, I am fine with typing out 2 passwords (LUKS + system login). But I was also interested in setting up FDE on my parents’ systems as a basic precaution against physical theft. My parents absolutely will not bother with FDE if they have to type multiple passwords and have stated they would rather not be protected than have to type a second password (basically, this is a real-world example of AviD’s Rule of Usability: “Security at the expense of usability comes at the expense of security.”).
For their systems, we would probably be going with either Fedora 33 (Cinnamon spin) or Linux Mint 20. I realize that there is a subjective decision that has to be made based on security vs. convenience. But first, I want to make sure that I correctly understand all of the options and the objective security implications before I discuss / recommend things to them. Assuming that manual entry of passphrase(s) during boot/login process is off the table, I think the following options all would work (with varying levels of security and maintenance):
-
Local-file auto-unlock: Setup an auto-unlock with
/etc/crypttabpointing to a local file and then mount the resulting encrypted drive in/etc/fstab. My understanding from the crypttab man pages is that (unless using_netdevas in option 3 below) it only supports either a binary keyfile, a text file containing plaintext password, or a plaintext password with no spaces entering directly in crypttab itself. I think that in all of these scenarios, something like this if an attacker has stolen the physical computer, it would then be trivial to gain access to the unencrypted files simply by booting up any live disc and using the password/keyfile to unlock the container just as the auto-mount does, no special tools required. IIUC, this is even worse than no FDE as it gives a false sense of security… I don’t think I would really even consider this and am just listing it in case I have grossly misunderstood something. -
USB-file auto-unlock: Same as option 1 but I could store the keyfile on a removable USB stick. Since my parents are very likely to leave the USB stick in the computer at all times (or at best to keep on the desk next to the computer), I don’t see this option as being any better than option 1. Perhaps even slightly worse bc it requires buying a usb stick and hogging one of the ports. Likewise, I don’t think I would consider this either but pretty sure someone would suggest it if I didn’t mention why it won’t work for us.
-
Network-file auto-unlock: Same as option 1 but store the keyfile on a networked device. To prevent the server device from being physically stolen along with the actual client PC, my best bets would either be to have something “in the cloud”/connected via remote storage OR to have a small device like a RaspPi that I can hide somewhere just for this purpose. Personally, I’m not too fond of the idea of cloud/remote keyserver connected via internet: I’ve never really trusted “the cloud” w/r/t to important data, I perceive internet to be greater risk than LAN, and I’d probably get bitched at about multiple password entries if the internet went down (they’re semi-rural so it’s happened here and there). The RaspPi sounds like something I could manage to set up on the LAN. But as I haven’t been following IOT stuff at all, I’m unclear if IOT security has managed to improve from “garbage” to something worth possibly considering. If it has, the main downside I can see is that I would need to spend some time learning ARM-stuff and then also maintain/update an additional device.
-
Tang-server auto-unlock: I am not sure if this is different from option 3. When I originally read about
_netdevoption in the crypttab man pages, I got the impression it was just a network-hosted keyfile on something like fileserver/NFS/samba. When I later ran across some Redhat documentation and opensource.com mentioning using Network-Bound Disk Encryption (NBDE) via a tang+clevis server setup, I assumed it was a different setup. But maybe they are the same? I am guessing that if they are different, then this option will have most of the same pros and cons, but it will come down to security of tang+clevis vs security of fileserver/NFS/samba – where I would expect the more specific implementation (tang) to win. -
Linux password auto-unlock: Make passphrase the same as the user password and replace
/etc/mounttabmappings with something like pam_mount. IIUC, there is some risk here that someone could boot up a Kali (or other) livedisc, look at the hashes in/etc/shadowand then run those hashes through some kind of cracking utility to help guess the password… something like a smarter brute-force that only targets matching hashes. This option is very hard for me to evaluate as I don’t know how to do this myself and am not really sure how easy/difficult this is for an attacker to actually pull off. Plus, I know my parents’ login passwords are not typically anywhere near as strong as my own which I suspect might make such an attack easier (but again no clue how much easier). If such an attack is not that easy, then this could be a really good option for me as it it’s probably a lot less work to setup/maintain than a key server. -
Skip FDE and just use VeraCrypt container: Not my favorite option (some files will probably be left in the open due to human nature/human error, browser profiles unprotected, and unencrypted copies of moved files might be viewable via recovery software). But I think I’ve gotten them used to storing important passwords in a password manager so they could just copy/paste that in when opening it. And more importantly, it would only be when they are working with important files – no 2nd password to enter on a regular basis. I suspect they’d still veto this option but I’ll keep it on the table until then.
-
Cheat: If they just don’t want to enter 2 passwords, I could probably set up a LUKS container normally (requires passphrase during boot via crypttab) and then setup a normal/non-root/non-sudoer user that does not require any password and just automatically logs right in. My gut reaction is to not do this but I can’t properly articulate / think of how to explain why this option would be “bad”. Only thing I can come up with is if the luks container doesn’t get locked on screensaver/sleep (and I don’t think it does by default – at least not in Cinnamon desktop), then anybody could just sit down and get the data without needing to physically steal the pc. But if that’s all there is, then I might be able to script a solution.
So my questions are:
A. Is my understanding of the security implications for the options above correct (especially on options 3-5)? If not, what did I get wrong/miss?
B. Are there any other options/solutions that might work in this situation?
C. If you have/had a similar situation what would you choose and why? (If it helps, I mostly interested in finding other things that I haven’t thought of or things I haven’t thought through well enough). LUKS has been around almost 2 decades… Surely I can’t be the only – or even the first – person trying to handle this type of situation 🙂
D. Consider this a bonus question / fine if you skip it. But for option 5 (linux password/pam_mount), I will admit that I am also a bit curious if my own passwords would fare any better for an attack that targets the hashes in /etc/shadow. Assuming I were to setup some dummy accounts on an old box and grab a Kali live disc, what tool(s) should I look into if I wish to attempt to see how good/bad that option is on my own? I am fairly proficient with Linux and Java but still haven’t gotten around to learning to do my own pentesting/whitehat stuff. Or if I need more knowledge than just a googling a specific linux tool, is there a book / tutorial / online course that you might recommend?
