Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add TPM2 systemd-cryptenroll to Tips and Tricks #176

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions modules/ROOT/pages/tips-and-tricks.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -160,3 +160,20 @@ or setup shell `alias`es as needed to make them available to the CLI like so:
$ alias evince="flatpak run org.gnome.Evince"
# or alias evince="org.gnome.Evince"
$ evince

== Enabling TPM2 for LUKS

It is possible to use the TPM2 device in your machine to automatically decrypt your LUKS-encrypted device. It is important to note a few things regarding this setup: first, it is trading convenience for security. Anyone who has access to both the disk and the TPM2 device can unlock your data. Second, it is crucial to keep a LUKS passphrase in addition to the TPM2 device that you can use to unlock the LUKS device; if you update BIOS, or the kernel shim, or make other substantial changes to your device, the TPM will refuse to sign your session and you will fall back to manually entering a LUKS passphrase. In this case, you can re-enable TPM2 for unlocking by re-running the enroll command below. This tip assumes you have a single LUKS device created during the Anaconda installer; if you have more than one LUKS device, you will need to correctly identify the device you want to enroll.
stenwt marked this conversation as resolved.
Show resolved Hide resolved

To set up TPM2 unlocking, first, find the LUKS device you want to enroll. This is probably in /etc/cryptsetup; you can also use `cryptsetup status /dev/mappper/luks*` to identify the device.
stenwt marked this conversation as resolved.
Show resolved Hide resolved

Next, enable the required initramfs and kernel features. Note that the initramfs command below will overwrite any other initramfs changes you have made:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the initramfs section should be moved to the "first step", with a note that it's only necessary for F40


$ sudo rpm-ostree kargs --append=rd.luks.options=tpm2-device=auto
$ sudo rpm-ostree initramfs --enable --arg=-a --arg=systemd-pcrphase
stenwt marked this conversation as resolved.
Show resolved Hide resolved

Then, using the device you identified with 'crpysetup status' previously, enroll the device:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Assuming that the previous suggestion to reorder the initramfs customization has happened, so that contextually the following changes make sense)

Suggested change
Then, using the device you identified with 'crpysetup status' previously, enroll the device:
Enroll the identified device:


$ sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/boot-device
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is 0+7 secure enough? Correct me if I am wrong, but changing the kernel parameters would allow to mount the disk and change the root password.

Copy link
Member

@travier travier Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not, but it's the best we can do right now as the kernel parameters change on every boot as ostree includes the hash of the deployment to boot in the kernel parameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's a good idea to recommend this because it will appear to work for a while, until such time as you update shim, and then it will break.

We discovered this in e.g. containers/bootc#421 (comment)

At least if you have this it needs to have a big warning label about this...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the fact that the TPM2-backed credential can stop working is well understood and has been discussed a few times in the diff discussions in this PR already

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the most recent wording I proposed here: https://github.com/fedora-silverblue/silverblue-docs/pull/176/files#r1721249426

So line 168 of my proposed changes would ideally be wrapped in some kind of styling element that turns that paragraph into a warning of some sort.

Copy link
Contributor

@samcday samcday Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I think the warning should be sufficient and that some documentation here should be merged letting folks know how to use this. shim updates seem to be about as regular as UEFI platform f/w updates from my perspective - that is, once every year or so... I boot my computer daily, so I'm certainly glad I only have to type my password once every 500-1000 boots nowadays, rather than every time 😅


Reboot; you should not be prompted to enter your LUKS passphrase on boot.
stenwt marked this conversation as resolved.
Show resolved Hide resolved