Streamline verification of root hashes, please
Opened this issue · 3 comments
Is your feature request related to a problem? Please describe.
When selecting the option to verify root fs hashes user is asked to enter disk tpm unlock password. After hashes are verified user is again asked for disk tpm unlock password to boot.
Describe the solution you'd like
The verify root hashes is a nice feature, but cumbersome to use because of the need to enter the disk unlock password twice. It would be much better to do the disk unlock once and then verify hashes and boot without needed to lock/unlock again.
Describe alternatives you've considered
At the moment the alterternative is to not use the verify root hashes feature.
If I understand correctly, you are asked to type Disk Recovery Key (DRK), not TPM unsealed Disk Unlock Key (DUK) passphrase to verify rootfs hash twice, and you would love the Disk Recovery Key passphrase to be a cached, reused passphrase to be able to be reused instead of asking you to type it twice?
If you are asking for the TPM DUK to be asked instead of the DRK, its a whole different topic. You would want the TPM DUK to be asked instead of the TPM DRK to verify rootfs hashes?
Note that this feature was developed per Purism (@JonathonHall-Purism ) and that Purism disable TPM DUK in their OEM settings and board configurations, therefore there is no TPM DUK in their use case, and DRK is asked twice there too, to rootfs verify PureOS and then to boot into the OS at systemd/equivalent or the librem key to unlock rootfs with a second factor authentication per their upstream documentations.
This rootfs feature is not used for QubesOS as of today either and would not be compatible, since too many things change under rootfs. So this feature is highly OS specific. Aslo note that on default QubesOS installation, accessing the rootfs under LVM would require additional code that is not under Heads either today to support that OS correctly either, since verifying rootfs (and reporting constant changes between boot) would require vgscan/lvscan mounting dom0 filesystem and then checking for rootfs hashes. All of whiich could be done, as well as opened tickets on QubesOS side to go in that direction but work needed on QubesOS side so that rootfs and dom0 changes are splitted more logically and this feature under Heads would make sense for its first and main use case: QubesOS. Until then, trying to fix this could be splitted in smaller steps to get to that goal.
Workflow: verify rootfs after TPM DUK asked, reusing the TPM DUK to check rootfs and if good, kexec into final OS?
Would require importing refactoring, but I do not see why it would not be feasible. Note that Heads will vary in usefulness epending of what is the final OS booted here on rootfs report, and rootfs checks can be massive and long, depending of what is checked there. Issues reported on that, requests for Heads to do a countdown and increase report on what files are processed for checksuming etc because user left in the dark while this happnes somehow.
I'm interested into getting your feedback here on what you would really want, weighting pros/cons of what I exposed here and what you would want to see accomplihsed here
@loftlifter31 As usual, use case, and feature sponsoring sources for extending features needed. Otherwise Collaboration on PR can happen on my free time. Best as usual is itching your own itch in a PR and asking my help there once issue here or elsewhere defines the problem to solve in actionnable terms where PR can fix the issue with a pass/fail state.
I won't have time anytime soon to implement this on my own, but can help if you see the angle to achieve that and propose PR to implement it.
I hadn't realized how complicated this feature request would need to be. I assumed since the rootfs check is already implemented, changing the process flow to leave the luks disk unlocked for boot into OS would be easy. But based on what you are saying here it would involve a significant effort. I still think it could be useful for heads to be able to attest to the known good state of dom0 before booting in the same way heads attests to the known good state of firmware and /boot, though it may not be worth the effort involved. I am not able to make any PR because I don't know coding. Maybe when github copilot gets to a point where it can write code based on user text prompts I can use it to write code for me, but until then I'm not much help for this.
I assumed since the rootfs check is already implemented, changing the process flow to leave the luks disk unlocked for boot into OS would be easy. But based on what you are saying here it would involve a significant effort.
Yes, I think the knowledge gap is that the "disk being unlocked" is not actually state of the disk/partition, it is state of the OS. The "disk is unlocked" means the OS knows a key that can decrypt the disk. We don't store that key in the disk anywhere (which probably makes sense 🙂 ).
Heads and the installed OS are separate "operating systems" for this sort of discussion. So to "keep the disk unlocked", we have to send Heads' knowledge of the disk decryption key to the installed OS.
Heads does know how to do that to an extent. That's for the TPM disk unlock feature that @tlaurion refers to - Heads obtains a disk decryption key through its own means, then sends it to the OS. But this is not integrated at all with the root hashes feature.
If you are asking for the TPM DUK to be asked instead of the DRK, its a whole different topic. You would want the TPM DUK to be asked instead of the TPM DRK to verify rootfs hashes?
IMO, if we break up the problem in the right way, it can be the same problem. E.g.:
- Do we need a disk decryption key? (We do if either a) TPM DUK is active or b) root hash is active)
- If so, obtain a key (TPM DUK flow if active, or prompt user for DRK if DUK is inactive or can't be obtained)
- If root hashes are active, mount root and check using the key above
- If a decryption key was obtained in 1, inject it to provide to the OS
- Exec the OS
A flow like that would integrate the two features better, I think either would work separately or they could work together. But of course there are a lot of details to work out 😉
I won't have time anytime soon to implement this on my own, but can help if you see the angle to achieve that and propose PR to implement it.
My time allocation is starting to open up again, and I do want to focus on ease-of-use in 2025. I don't know where/if this change specifically will fall in the priorities list yet, but it is an ease of use improvement to make Heads security features more accessible, so I'll certainly consider it as part of our roadmap 🙂