Hi everyone !
I’ve browsed a lot on this forum, and I never found any reliable way to achieve home-folder encryption with login password.
I’ve found posts talking about PAM rules, systemd-homed,… but everything I tried never worked as expected. Also, I never found good documentation on the subject, expect the one from the Arch wiki, but again the instructions didn’t work for my on a fresh Fedora 42/43 installation.
Does anyone know about how to encrypt the home dir with the login password ?
And I know it’s better to use LUKS FDE, however It would still be a good option for people who don’t want to deal with 2 passwords for they computer.
The issue is that if you ‘only’ encrypt /home/$USER, you leave the machine open to attacks where someone places malicious code on your disk. But an encrypted /home/$USER would protect (mostly) against theft.
In the end, it all depends on the attack scenario that you want to protect against.
building-a-new-home-with-systemd-homed-on-fedora has lots of information about systemd-homed. This post was created to bring forth information on the workings of this systemd component so that a wiki could be created from it’s knowledge.
It is hard to understand unless you read the whole post and ran into the issues mentioned in this post. It was also written before it was ready to be used on fedora.
ATM, the only necessary steps to use systemd-homed on fedora is to enable the systemd-homed PAM and to create and relabel your newly created home directory for it to function properly.
I remember dealing with PAM rules was something I struggled with, because I was not able to find which files to edit on Fedora (some files mentioned on the arch wiki was not available for example).
But in fact this post looks full of information, I will try again when I’ll have the time. Thanks !
If I remember correctly, even with Clevis I had to re-enter the disk password after every kernel update. Do you know if it’s still the case or if there’s a workaround for this ?
I tried to create a new user with systemd-homed’s homectl command, but he never shows up in the login manager (for both GDM and SDDM).
Also when I tried to follow the instructions from this thread, I manage to create the user.home encrypted directory but it’s not actually used by the user and still uses its old unencrypted /home. Do you have solution for any of this problem ?
I would recommend FDE with a passphrase, and if don’t want to remember two different passwords, then just choose the same one for FDE unlock and login (which also works on multi-user systems, luks has 10 slots for unlock passphrases)
which has advantages (ease) and some disadvantages: if you computer gets stolen, your data is not safe; if your motherboard dies or needs to be changed, your data will be hard to unlock.
… is not mature, and requires a lot of manual setup work. in my personal opinion, it’s too early to recommend the technology.
Yes, it is a bit involving to set it up (but not too much) and works as expected in simple use cases. But there are situations, where homed is not ready yet, e.g., if user wants/uses toolbox/distrobox. If the main goal is to have encrypted homedir for files, settings and flatpak apps (installed to --user) - it is OK, IMHO.
GNOME OS devs are working on having homed better integrated to the GNOME DE.
you can put secondary password or recovery key in case you changed hardware and re authenticate with TPM on the newer hardware.
EDIT : you can use passkeys too
the article i sent to you is not conclusive you can read more about luks2 and TPM @theprogram gave you a very good guide
the security depends on the hardware implementation of the device however it’s not that easy .. it require special tools and specific exploits depends on the hardware manufacture so even if someone stole it unless he is determined to decrypt your data and have the tool and the knowledge it won’t be easy after all it designed to prevent that in the first place so it’s not open doors
i am just wondering wouldn’t automatic decrypting your home directory pose the similar risks after all the encryption key is in your ram and your OS is not encrypted.
and to be automaticly decrypted you have to put the password somewhere. i think TPM or passkeys is the best answer to what you do and more secure than what are you trying to do
if you want the maximum security go full software encryption and use UEFI to decrypt with secure boot and enabling validation. or use TPM FDE with passkey and fully encrypt you disk
but you will lose the convince .. you have to chose
I wonder if a yubikey or similar device that acts like a keyboard to enter a (strong static) password by touching the key would make it easier to use configurations that too often require entering a password.
That is true and anybody using LUKS2 should always add a recovery key and store that safely, along with other emergency documents that tell people how to get access to your accounts/data in case something happened to you.
That assumes that an attacker would go after the TPM, which is indeed relatively complex.
However, the issue I see is that most people who do this do not secure their bootloader. As long as an attacker can simply edit the kernel commandline and add rw init=/bin/bash, the TPM will happily provide the key for LUKS2 and the system will drop you into a root shell, where you can change passwords for any user account or simply access all files directly.
Sure, you can tie the LUKS2 key to additional PCRs in the TPM. But the issue is that GRUB does not just measure the kernel commandline but the entire boot stanza (into PCR8), which includes the vmlinuz filename, which in turn contains a version number and thus changes with every kernel update. So after every kernel update, you need to get out another (recovery) key, type that in, and re-enroll the TPM key after you booted up with the new kernel. Alternatively, you could look into PCR9, into which the kernel measures its commandline (which we want to protect against changes) but also its initrd, which must change with every update and thus also breaks the TPM unlock every time.
Plus, when I tried that, I ran into an issue where it didn’t prompt me when TPM unlock failed, I had to boot a live system first, remove the TPM enrollment, and then boot into the system with my passphrase. I quickly decided that typing a complex passphrase once but reliably during boot up was not so bad.
Check out man systemd-cryptenroll, you can actually enroll a FIDO2 device like a Yubikey (and not use it for the static key). Though I must say I haven’t tried that yet.
The advantage I see here is that this is decoupled from the computer and its TPM, so an attacker would have to steal both the computer and the security key. Plus, these keys usually have a PIN that needs to be entered, so even if an attacker gets both, they have only a limited number of tries. (For the FIDO2 key I use, it’s limited to 8 tries.)
thank you for the insightful reply i learned a lot
i came to the same conclusion but for different reasons nothing more safe than my head to store the password
yes there was a good discussion about it i don’t if there is a way to look down GRUB to not accept the CMDlines configuration during boot that could be a middle ground .. [Didn’t try it myself]
EDIT: after some reading it appers people could put password on grub edit grub2-setpassword
they also mentioned a PIN that could be added using systemd-cryptenroll with TPM. that worth checking out too [i just noticed you mentioned this for Hardware keys it appears it can be combined with TPM too]
theoretically if someone made FDE using TPM(PCR 7) + PIN + bootloader hardening (passwords .. etc ) he will have a good security and convince if i understand correctly
That’s what I meant when I wrote people don’t secure their bootloader.
True, you can set a PIN when enrolling a TPM, though I haven’t tried that. And I also haven’t seen a guide that recommends it.
This is probably the best solution, and also something I have seen companies enforce in their Bitlocker setups (Windows, of course). It makes sniffing attacks (where you listen for the key on whatever bus the TPM is connected to) practically impossible, because you need someone to provide the correct PIN for the TPM to release the key, in addition to the correct Secure Boot PCR values.