I really LOVE the new installation flow in F42, and especially the ability to encrypt a drive through the GUI.
However, I am curious why Fedora didn’t merge the decryption of the drive and the unlocking of the user account? Currently, if drive encryption is activated, we have to first enter the password to decrypt the drive; and then enter the password to unlock the user account. In other operating systems, these two tasks happen at the same time with a single password, which is very convenient.
This is possible if you encrypt /home using different encryption mechanisms than cryptsetup—for example, using pam_encfs. However, the setup Fedora uses is better and likely more secure. For a single user, you can achieve a similar effect by using autologin.
I believe the poster is referring to macOS, which does work like that.
Simply put, no one has written software for that yet.
On Linux the path forward seems to be to leverage attestation (i.e. via TPM) to unseal the system drive on boot, similar to Windows, then uses systemd-homed to manage user-encrypted home areas. This would present itself as booting directly to desktop, then only when you login would your user data be unlocked (similar to iOS/Android).
At the moment, GNOME is making strides towards this in GNOME OS, but the technology is relatively new and would take awhile to be integrated in upstream projects and make its way to Fedora.
There is a systemd subproject to encrypt the user’s home directory and link the login process with decrypting the the data. See https://systemd.io/HOME_DIRECTORY/
It takes a bit of effort to set up and it makes your system deviate from the standard setup, which could make support difficult.
macOS scheme is actually a bit similar to TPM/Secure Boot with their Secure Enclave key hierarchy management . The details are different, but I don’t think that is the point of this discussion.
It is possible to do something similar with Linux by utilizing UKI, TPM, and enrolling the keys there while signing everything. However, it requires a lot of work to do it securely.
On Linux the path forward seems to be to leverage attestation (i.e. via TPM) to unseal the system drive on boot, similar to Windows, then uses systemd-homed to manage user-encrypted home areas. This would present itself as booting directly to desktop, then only when you login would your user data be unlocked (similar to iOS/Android).
Or just use pam_encfs. I still think that using cryptsetup with autologin is the best solution, assuming you’re the only user of the machine.
I was referring to macOS UX. You have to put your user password in before your drive is “unlocked” and the system can boot when you enable FileVault, and you can register more than one user to be able to unlock the drive on boot. This would also log directly into that user after boot, so you avoid double password entry. There are no Windows/Linux equivalent to this.
systemd-homed major advantage is providing an API other software can use, so GNOME is adding integration with it, which gives it a better chance at becoming a mainstream setup. But for your local setup you can just use whatever, I agree.
pam_encfs works by encrypting each /home directory separately, using the login password to derive the encryption key. The user experience is the same; the difference is that / remains unencrypted in this case. systemd-homed can achieve similar functionality, but with cryptsetup or fscrypt.
Using systemd-homed or pam_encfs in conjunction with TPM enrollment would create a model very similar to FileVault, where the system volume is encrypted and protected using Secure Boot, and the user home directory is encrypted with a per-user key. However, setting this up requires a lot of work, and in my opinion, it offers very few advantages compared to other methods.
On the other hand, cryptsetup with autologin prompts the user for a crypto password without requiring a double entry. The limitation here is that this approach only works for single-user machines.
Note that with FileVault 2 (which is the current system in use, at least on my Intel Mac), the system volume is authenticated by the user on boot, then the system is booted. Please refer to Appendix. B of this document for more details.
But besides this, I interpret the original post as asking why Fedora doesn’t do this by default, not how to set it up for their system, of which I outlined the various pieces of the ecosystem that still have to be put together before Fedora can provide a solution ready for mainstream use.
If you are interested in how it actually works now, please refer to https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf for a more up-to-date description of how it works with current Macs (including yours, assuming you are running macOS 11+ and have a T2 chip—everything has it except for very old Macs from 2017 and earlier). Core key management remains, but there have been several updates, such as SSV.
That is why I said it is encrypting /home instead of saying it is FDE. And in fact, systemd-homed doesn’t have to use FDE / cryptsetup; it can also use fscrypt on supported filesystems (ext4 / F2FS), which is more similar to how encfs works (FBE).
However, I also mentioned that I think cryptsetup / LUKS, which Fedora provides out of the box, is the best solution for most users.
We have to acknowledge that most desktop users are only benefiting of the features that come OOTB or can easily be implemented. That means that at the end of the day, on disk-encrypted multi-user systems (e.g. desktops or laptops shared by family members), when booting/rebooting, (1) a Mac user has to enter only one password, which decrypts the system volumes and logs in the user, whereas (2) a Fedora user enters the LUKS password, and then the login password[1].
There’s no contradiction in loving our Fedora/Linux desktops, and yet appreciate the usability features that other OSs are providing, it’s what drives us forward.
At best each user’s login password can be added as LUKS passphrase too, so that each user has to remember its own password only. ↩︎
There is no disagreement about that; however, I would be personally very interested to know if there is any telemetry (from Fedora or elsewhere) regarding how prevalent multi-user setups with encryption are. To be honest, they really don’t make much sense unless people use unique, strong passwords and you enforce that.
I don’t see shared devices often anymore, but even when I do, I haven’t seen, for example, even FileVault enabled on them (it is not enabled by default).
Telemetry didn’t get implemented on Fedora, as of yet. Speaking from personal experience, I always recommend disk encryption on laptops, and I image that while not a majority, there still are multi-user setups out there. This forum’s users are certainly not representative IMO.
I am a Mac user at work, having both an Intel Mac with T2 chip and an Apple silicon Mac, and encryption is enabled on both. Having run the initial setup on these myself, I don’t remember if FileVault was enabled or disabled by default (opt-in or opt-out), but it certainly was part of the setup process. Also, enabling/disabling FileVault on these systems is a matter of a couple of clicks, given that disk encryption is on Intel T2 chips and Apple silicon enabled by default.
Yeah, I am all for encryption by default, but I’m just saying that in multi-user systems, unless there is a strong password policy, it’s pretty much useless. Of course, secure boot and TPM could help in this scenario (protecting the operating system’s integrity), but unfortunately, we are not there yet for the masses. For the record, I am not a big fan of secure boot and TPM schemes, but the fact is they provide a huge security improvement for users who won’t use strong passwords.
I am a Mac user at work, having both an Intel Mac with a T2 chip and an Apple Silicon Mac, and encryption is enabled on both.
Well, first of all, work Macs will often use ADE/MDM, so that might not be the best example.
Modern macOS will always sign the system volume using SSV and encrypt volume using a VEK, which is derived from the hardware key. The difference (I am simplifying) with FileVault enabled is that it is also derived using a KEK. The whole scheme utilizes the Secure Enclave.
This is essentially what you get with SB, TPM, and cryptsetup enrollment on Linux, and perhaps one day it will become the default.
And if I recall correctly, during the normal onboarding process, it will offer you the option to enable FileVault if you opt in to sign in to iCloud. If you opt out, it will be disabled. However, storing the FileVault key in iCloud doesn’t seem like a particularly good idea to me.
And in fact,