How good/bad are these transparent Linux consumer FDE setup options? (e.g. for auto-unlocking LUKS)

Question

UPDATED 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 found/thought of several options and tried to think through the security implications of each... but I am not great at infosec. Mostly I am wanting to verify that I have correctly understood the pros/cons of each option.

I have seen several people ITT and others mention an "Evil Maid" attack... But that seems to imply the maid is someone who doesn't know computers. I've heard it said that it is bad to underestimate one's opponents; it is also true that neither technology or tech-skills sit still... So I'm more interested in protecting from an "Evil Maid + Her Linux-Hobbyist Boyfriend" attack. Apologies for the length; hopefully my edits have trimmed it down a bit.

I am looking into using LUKS/FDE for a Linux /home partition setup for my parents a precaution against physical theft. In an age where there are many tech savvy people, I don't think it at all unreasonable that even a computer illiterate thief might at least "know a guy" who dabbles in Linux. So I would like to protect to at least the level of making things too frustrating for a Linux hobbyist to pursue.

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.").

This will be on a mix of Fedora 33 (Cinnamon spin) and Linux Mint 20 systems. I am mostly trying to eliminate truly "bad" options and present them with a list of viable options to choose from. I realize that there is a subjective decision that has to be made based on security vs. convenience - that is for them to decide, I am just trying to make sure that I understand it well enough to pare it down for them. :-)

I think all of the options I have listed would produce a transparent (e.g. single-password entry) FDE system. But I don't think the security/maintenance of each is equal. I am especially interested in whether options 5 and 7 have any glaring security flaws which are easy for someone with a Kali livedisc to quickly exploit (say less than a week).

1. Local-file auto-unlock: LUKS can be auto-unlocked with an /etc/crypttab entry pointing to a local keyfile per crypttab man pages. Pros: easy to setup/maintain/etc. Cons: False sense of security: anyone with a Linux livedisc could easily use the same keyfile to gain access to the unencrypted files, no special tools required. Some people consider putting the keyfile on a USB stick to be different; but my parents would either leave it plugged in or keep in next to the computer so I am lumping them together. I don't think I would really even consider this and am just listing it in case I have grossly misunderstood something.

2. Merged into option 1 for brevity but trying to keep same order so replies make sense.

3. Network-file auto-unlock: Same as option 1 but use the _netdev option in crypttab to get the keyfile from a network device. To prevent the key server device from being stolen along with the PC, best bet is probably to hide a RaspPi etc somewhere as the key server. The main downside is another device I have to learn/maintain. Another downside is that last I checked IOT security was garbage (I might be out-of-date though).

4. Tang-server auto-unlock: Basically option 3 but using tang + clevis instead of just hosting keyfile on fileserver/NFS/samba/whatever. Same cons as option 3 but probably more secure in the server software.

5. Linux password auto-unlock: Make LUKS passphrase same as Linux user password, then replace /etc/mounttab mappings with something like pam_mount. Pros: sounds easy to setup, low maintenance, good usability. Cons: There is some risk here that someone could boot up a Kali (or other) livedisc, look at the hashes in /etc/shadow and 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. But no clue how long this might take the "average" Linux hobbyist with "average" consumer hardware.... Is it days or weeks? Or something that only takes a few hours or less? If this is kind of attack is easy to pull off on plain hardware, then I'll pass; but if not, this could be a great compromise for setup/maintenance/usability/security vs setting up a key server.

UPDATE: This seems very dependent on the password used... trying simple tests using john against the unshadowed hash for password test took ~8s. The same test with password example took ~8m. Trying with an old 5-digit numeric garage door pin I no longer use... it's been running for over 11.5 hours and still hasn't got it yet. That said, I'm using an older mid-tier consumer gaming rig, I'm running with defaults and no distributed cloud/custom dictionaries, and haven't tried hashcat yet... I expect any/all of those things could yield better results (from the attacker's perspective).

However, the more I think about this from a computer science perspective, the less I like this approach. Unlike with a web-service or crypto-container like LUKS/VeraCrypt, attackers aren't just blindly trying to guess the password. They already have something that tells them what the correct password will be and it is just a matter of doing the legwork. So why couldn't the legwork be done up front and stored in a database/lookup table. I am very much a novice when it comes to this stuff. But what if there was a tool that pre-computed hashes into such lookup tables and combined that with other techniques to drastically ramp up speed? Google searches indicate things like this might already exist. Maybe the "Linux-Hobbyist Boyfriend" attacking the drive is ignorant of them like me, but considering that LUKS doesn't appear to expose its password hashes, this option would definitely make attacking a LUKS partition easier if such a tool does exist unless there is some way to have Linux not store the hash in /etc/shadow (I am unaware of any such method/configuration shy of heavily modifying the kernel).

6. Skip FDE and just use VeraCrypt container: Still a few usability cons here and I'm not sure they'd like this option. There are also a few security cons (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). Pros: easy to setup, easy to maintain, and any data that is stored correctly is very secure. Cons: usability (still have another password to manage), some security gaps.

7. Cheat - FDE + auto-login w non-sudo user: 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. After looking into this more seriously, and assuming it was only the auto-login on the desktop manager that was used (e.g. user-account was still password-protected), then this seems like a fairly viable and secure option... as long as we don't get any more prodigy hackers attacking lockscreens. Pros: easy to setup/maintain/FDE. Cons: ??? Can't find any...

8. Systemd-homed?: While looking into the security of option 5, I came across this article on systemd-homed which it sounds like that is a more secure version of option 5 where you get the LUKS encrypted container for the user's $HOME dir (sounds like it is per user rather than all of /home tho) and possibly without the risk of someone being able to simply fire up a cracking tool against password hashes from your unencrypted /etc/shadow file. It appears to be released and there are notes on the arch wiki. However, I am not yet clear on: a) how stable is it in common distros like fedora or mint, b) is the json file that is replacing /etc/shadow similarly vulnerable to live disc snooping and cracking tools.

---

I was considering removing this question as I think I have done a poor job of constructing it in a manner than is easily answerable on stackexchange and I also feel like I did a bad job conveying what I was looking for when I initially posted it... I think that the real problem boils down to the fact that I have asked about a topic that requires answer multiple questions instead of asking about a single specific question.

However, I've been revising it and adding updates from my own research and now I am considering leaving it up in case it is useful to others that might stumble in from google... Assuming stackexchange mods don't mind?

semi-relevant remaining research questions I'm still working on:

• For option #5 (and maybe 8?): Are there any estimates about how long it would take to crack non-leaked passwords (based mostly on haveibeenpwned offline db) using low-to-mid range consumer gaming hardware without distributed/cloud-based attacks or crypto-mining rigs? e.g. commonly available hardware that someone a thief might know could reasonably have. Since length/entropy matters, the examples I had planned to test with (subpar to the actual passwords) have been 5- and 10-digit random numeric "passwords", then 8-, 10-, and 12- digit random alphanumeric "passwords".

• For option #5 (and maybe 8?): Need to determine what "good" parameters or dictionaries to use with john / hashcat are and/or if there are better (faster) tools for cracking from a known password hash. If I am able to get the time for cracking non-leaked random 10- or 12- digit alphanumeric "passwords" down to a week or less on my older gaming hw, I will probably consider that option to be completely and utterly busted.

• For option 8: how stable is homed? Does the json file have the same vulnerabilities as option 5 does in the /etc/shadow file?

---

Currently, as of 2021-Jun-11, my opinion of the options is as follows:

1. Local-file auto-unlock: NOT SECURE ON-SITE: Vulnerable to any live discs
2. USB auto-unlock: NOT SECURE ON-SITE FOR US: Vulnerable to poorly hidden usb + live discs
3. Network-file auto-unlock: DON'T BOTHER; OPTION 4 IS BETTER
4. Tang-server auto-unlock: LOT OF WORK, POSSIBLY INSECURE DUE TO IOT, ADDED COSTS (RASP-PI)
5. Linux password auto-unlock: NOT SECURE ON-SITE. Depending on tech level of the thieves, it is potentially vulnerable to live discs. It will likely take longer to break than option 1 but it definitely can be broken if someone has a spare box to run the password cracking on for awhile. In my limited testing, I also tried 3 different pam_mount configurations without success on Fedora 33 so possibly also harder to setup than I thought.
6. Skip FDE and just use VeraCrypt container: SECURE BUT USABILITY ISSUES
7. FDE + auto-login w non-sudo user: FAIRLY SECURE, HIGH USABILITY
8. Systemd-homed?: UNKNOWN SECURITY, UNKNOWN USABILITY

I am leaning strongly towards option 7 (LUKS + autologin). If it doesn't work, I might look into option 8 (homed) or option 4 (hidden rasp-pi running tang server) as fallbacks.

Answer 1

Configure secure boot and use LUKS for FDE along with initial user login password for accessing the system.

You can go with any one of the options 2,3 or 4 for storing the LUKS keys. It will provide some level of security wherein if someone stole your laptop and do not have access to USB or Network (from where keys are accessible) it will infeasible to decrypt the disk.

This will provide you decent level of security if physical attacks are not a concern for you. At last, you can harden the system.

You can also configure the login user which do not have root privileges and can do most of the stuff on the system and keep root/sudo user password with you and provide in case required.

But if physical attack like evil maid is a concern for you TPM is the solution i.e., trusted boot and Linux FDE.

Also, you are thinking too much if your only concern is related to basic security.

Answer 2

My recommended solution after using this for awhile is similar to TimothySimon's (I agree that FDE + autologin is the most feasible approach) but with an important difference as follows:

1. Before you deal with /home or data partitions, first set up an encrypted OS partition (/) using the same user password as LUKS. This ensures that /etc/shadow is not viewable via a physical attack with a live disc / etc. Some distros like Fedora 35+ provide an option to do this for you automatically. If creating manually, note that the /boot partition must still be unencrypted. This is the important difference I noted above: while an attacker having access to /etc/shadow would still require them to brute force the password, it would give them some hints (salt and hash) making it easier for them to crack your user password if they were determined (as the cracking could be done in memory without needing to test each attempt against LUKS directly). If the attacker had access to the root filesystem (e.g. it was unencrypted), they would likely also be able to confirm via various config files that your LUKS password is handed off to unlock the user account (and thus are the same password). This was the part that I struggled with the most when I originally created my question and why I had such difficulty in forming a good question in the first place.
2. Then set up a /home partition and/or any data partitions, also using LUKS, and also using the same user password. Again, some distros like Fedora 35+ offer an option to set this up for you.
3. Next set things up so that you only need to enter the password once to unlock all of the LUKS partitions using the same password. From root account, and using blkid to determine UUIDs, configure /etc/crypttab so that the 3rd and 4th columns match for all LUKS partitions that you want decrypted by the same password entry; e.g. <dev-mapper-name> UUID=<UUID> <label> luks,keyscript=decrypt_keyctl might be home UUID=<UUID> encrypted_partitions luks,keyscript=decrypt_keyctl; just use the same arbitrary name and 4th column params for all of the disks you want decrypted when you enter your password.
4. Setup auto-login in your Desktop Environment so that you don't have to enter your password again to log into the graphical session.
5. Optional, but I also recommend if you are using a Gnome-based DE such as Cinnamon that you setup Gnome keyring (aka "Passwords and Keys" or seahorse) to use a blank password. In non-LUKS setups, seahorse generally uses your user password to unlock the keyrings but this is usually done automatically by a PAM hand-off and is generally transparent to the end-user. Due to some limitation/design-constraint, this hand-off does not appear to work when one uses auto-login and the end-user will instead be prompted to enter their credentials manually when they use things like Chromium-based browsers, samba-credentials stored in Nemo, etc. Using a blank password would normally be bad but in this case, the keyring itself is still secured at rest by LUKS and the blank password eliminates the need to enter your login password again. Prior to doing this, the extra prompt was a huge usability issue on my parents' machines that nearly resulted in them having me emove LUKS and go back to the "old way" (For those that don't see the importance here, please see AviD's Rule of Usability).

Answer 3

Apply Full Disk Encryption, then configure Auto Login. The user needs to type just 1 password (The FDE password) while turning on the system.

Screen Lock, Logout, Password on resume from suspend etc., should work as expected, and ask the login password.

For greater usability, you can also use the same password for both login and FDE, at the cost of a very slightly decreased security.

This is what I do on my main system (FDE, Autologin and FDE password == Login password).