heads
heads copied to clipboard
linuxboot
WiP: Improve checksum verification upon totp unseal errors
Raw notes:
- Writing multi-line output to /dev/kmsg didn't work. We now output the message passed to DEBUG one line at a time.
- When TOTP unseal errors happened, the user needed to also sign /boot without knowing if /boot was tampered with.
- Now integrity report is given when totp unseal fails
- If gpg detached signature or hashes are invalid, we give the user a detailed report of hashes being different if detached signature is good (kexec.sig of kexec*.txt)
- There were multiple instances of verify_global_hashes
- The one from gui-init has been moved to etc/functions while others have been deleted, and calls requiring to update the hashes now pass optional parameter "update"
- Are some /tmp/hash_output relevance missed somewhere?
What should be improved further?
Played around with qemu-fbwhiptail-tpm1-hotp, qemu-fbwhiptail-tpm2-hotp and love the improvements.
From reviewing verify_global_hashes, it looks like there were significant differences between these two functions. We can't just replace one with the other.
In particular:
- The one in gui-init returned 0 or 1 for success/failure. The one in kexec-select-boot always returned 0, instead it set valid_hash=y and valid_global_hash=y for success and left them untouched for failure.
- The one in kexec-select-boot also checks root file hashes. The one in gui-init did not.
- The one in kexec-select-boot used "$gui_menu" to control whether differences are shown or just checked silently, the one in gui-init did not.
I do think this needs to be refactored, but we can't just replace one with the other.
Thinking back to the actual intent of the change - why do you want to report /boot integrity when TOTP/HOTP unseal fails? Seems like this is adding another prompt in an already nontrivial flow, and I think it'd be hard for users who aren't experts in Heads to understand what this information has to do with the issue at hand.
When TOTP unseal errors happened, the use needed to also sign /boot without knowing if things were right.
TOTP/HOTP re-seal doesn't affect the integrity of /boot. Why would you need to sign /boot without knowing the prior status in this case?
The intent of this was once again for tpm disk unlock key specifically but more globally for users to not sign /boot content when totp unsealing fails and resealing totp.
When one updates totp, tpm Disk Unlock Key needs to be updated (which takes totp + runtime measurements into another sealed secret which is authenticated) , but doing so, LUKS header changes and its local hash kept under /boot changes which is signed under kexec.sig and needs to be updated.
On tpm2, primary handle needs to be updated as well.
As for pre trigger and post trigger files under /boot, I will have to check history to see which os populates those and if they are still relevant. I do not use any OS doing those but thought probably wrongly that pureos was the intent of support here. Will check later but as of now I think the unification of those functions will need more thinking.