I tried this on Workstation a few months ago and it worked like a charm.
Idea is that encrypted volume is automatically decrypted on boot using tpm2 chip.
More info here: https://techrevelations.de/2019/02/04/tpm-encryption-in-fedora-linux/
Currently, the only possible problem I see is clevis-dracut package. Would this work with rpm-ostree initramfs --enable option?
Or does maybe someone has a better approach for this use-case?
I use such a setup as my daily driver so I can confirm that you can do this with some caveats, namely that Silverblue does not actually validate the integrity of initramfs images or kernel command line parameters under Secure Boot, allowing for pretty trivial bypassing of the TPM security if someone has extended access to your machine (see initramfs: signature checks · Issue #1920 · coreos/rpm-ostree · GitHub).
If your only goal is to provide some reasonable security against casual attacks on the root drive but still protect your data, I would recommend using this approach along with ecryptfs which encrypts your home folder with your login password as an additional layer of protection (see 1701347 – 'authselect enable-feature with-ecryptfs' fails to run on Fedora Silverblue 30, even when prompted to do so by ecryptfs-util's ecryptfs-migrate-home command. for doing this on Silverblue).
You will indeed need to enable client side initramfs generation for this after layering the clevis packages and doing a sudo clevis luks bind -d /dev/whatever tpm2 '{"pcr_bank":"sha1","pcr_ids":"7,11"}' (7 and 11 are what Bitlocker uses, which is better than just the 7 the post you found indicates).
Also you can fix the password prompt appearing during TPM decryption with the following:
sudo systemctl edit systemd-ask-password-plymouth.service
[Service]
ExecStartPre=/bin/sleep 10
and
sudoedit /etc/dracut.conf.d/systemd-ask-password-plymouth.conf
install_items+=" /etc/systemd/system/systemd-ask-password-plymouth.service.d/override.conf "
(then trigger a new initramfs generation)
Doesn’t this defeat the purpose of encryption your system? One would simply
need to get ahold of your system to get unencrypted access to your data. If
you don’t lock down GRUB, you’ve just handed over your system. If you don’t
lock down your BIOS, you’ve handed over your system. Otherwise, one would just
read your TPM’s keys, or, if that’s not possible, just grab the TPM itself and
they’ve got your data. What’s wrong with decryption keys, either a device or
passkey to unlock the key?
@plailect thanks a bunch
@JohnMH I might be wrong, but my BIOS is locked, secure boot is on. Therefore auto-unlock will only work on my machine?
That’s not easily doable. You’d have to sniff the bus.
Grub is locked down when secure-boot is enabled, although I personally wouldn’t trust it (Grub is a definition of bloat).
This is a case where physical access means you’re toast. All they’ve gotta do
is hit the power button.
GRUB is not “locked down” with Secure Boot enabled, you can still enter your
own kernel cmdline.
Although arguably Dracut would then never get the chance to deencrypt the storage.
Imho if you want easy encryption where you don’t need to give friends/family the password to turn the computer on, the best choice is home directory encryption. TPM/Bitlocker works okay on Windows because the bootloader and the boot process is locked down, and until it’s the same on Linux I don’t see it being secure.
I guess some solution would be for dracut images to be signed by Fedora, which would break the Nvidia modeset driver, and only allow certain kernel arguments.
Although arguably Dracut would then never get the chance to deencrypt the
storage.
Why not?
Imho if you want easy encryption where you don’t need to give friends/family
the password to turn the computer on, the best choice is home directory
encryption
If that’s your goal, fine, just don’t expect any security value from it.
TPM/Bitlocker works okay on Windows because the bootloader and
the boot process is locked down, and until it’s the same on Linux I don’t
see it being secure.
The Windows bootloader isn’t locked down either. If you’re using a TPM to
unlock a Bitlocker volume, that’s just as easy to get as well.
I guess some solution would be for dracut images to be signed by Fedora,
which would break the Nvidia modeset driver, and only allow certain kernel
arguments.
And then you’d have no way to recover the system.
There’s no reason to be adverse to hardware tokens and passkeys. They work.
You’d need some sort of recovery-key/password that can be used if the TPM can’t be used for whatever reason, similar to Bitlocker.
I don’t see how this is relevant to the lack of a recovery option through the
bootloader in the system you describe.
As with all security stuff, it all boils down to Who is your enemy?
For random dude that’s gonna steal your laptop it’s pretty safe, if you are targeted because of data then probably nothing will help.
There is no effective difference between just using a password on your user
account and using LUKS + TPM, in this aspect.
For “random dude that’s gonna steal your laptop”, just that password on your
account is enough to keep them from getting your data. However, here’s the
thing. Using LUKS+key with passphrase or physical token makes it much more
difficult for anyone to get your data, even, potentially, a state actor.
Correct me if I’m wrong, but is this not where the TPM comes in though to ensure that each step of the boot process is verified?
UEFI Secure Boot verifies the Windows Bootloader is signed, which then verifies the kernel, userspace services etc are signed.
“Verified” does not mean that it just boots the OS, and nothing more. It also
has nothing little to do with the TPM. The TPM is just a key storage device.
When using UEFI + Secure Boot, it means simply that the signature of the PE
binary that was used to sign the bootloader is checked against a public key
stored on the TPM. That doesn’t mean you can’t just boot to recovery, or
Windows’ safe mode.
The Windows pre-boot environment (which I think exists on the recovery partition?) will ask for a recovery key if you try and do these with Bitlocker enabled, it won’t go through the TPM.
It actually depends on how you go about getting to the recovery prompt. I’m
not talking about BitLocker’s recovery, which happens a bit earlier in the
Windows boot process.
As for GNU/Linux systems, well, it’s just a kernel cmdline change. It has no
effect on the boot process or verification, unless you specifically configure
GRUB to require a password to change options or enter the console.
So basicly, if you add password to GRUB for any changes, you are OK again?
Yes, if you lock down the BIOS so external boot media can’t be used and you
remove the default keys for Windows.
So we actually found a solution.
What do you mean by default keys for Windows?