Bug 1216244 - "Trusted Boot" with PCRS 2+4+7+8+9 should state reason for asking password on boot
Summary: "Trusted Boot" with PCRS 2+4+7+8+9 should state reason for asking password on...
Status: RESOLVED WONTFIX
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Bootloader (show other bugs)
Version: Leap 15.5
Hardware: x86-64 openSUSE Leap 15.5
: P5 - None : Enhancement (vote)
Target Milestone: ---
Assignee: dracut maintainers
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-14 17:23 UTC by Alexander Krupp
Modified: 2023-11-10 09:43 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Krupp 2023-10-14 17:23:51 UTC
On a system with unencrypted (but measured) /boot and encrypted / with Leap 15.5; configured with Secure Boot and Trusted Boot in Yast with additional

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=2+4+7+8+9 /dev/mapper/system-root

After modifying /boot (e.g. echo >> /boot/grub2/grub.cfg) the initrd asks for a password. This is correct. 

IMHO it would be beneficial to also state something like "PCR 8 measurement failed", or "your /boot partition has been altered".

May I suggest to introduce such a diagnostic message into the boot screen? Otherwise the damage is done by entering the password without second thoughts.
Comment 1 Antonio Feijoo 2023-10-26 10:45:10 UTC
This is definitely not a problem that can be resolved by the bootloader team. Let's take a look from the initrd perspective.

(In reply to Alexander Krupp from comment #0)
> IMHO it would be beneficial to also state something like "PCR 8 measurement
> failed", or "your /boot partition has been altered".
> 
> May I suggest to introduce such a diagnostic message into the boot screen?

The message is already logged to the journal by the systemd-cryptsetup service, and adding `systemd.log_target=kmsg` to the kernel command line would make it visible at boot:

```
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Started Forward Password R…s to Plymouth Directory Watch.
[  OK  ] Reached target Path Units.
[  OK  ] Found device /dev/disk/by-…0-eaaa-4a73-a803-94e5a861dbd0.
[  OK  ] Found device /dev/disk/by-uuid/1C32-AB8E.
         Starting Cryptography Setup for cr_root...
[  OK  ] Found device /dev/disk/by-…9-1ab4-42a0-bebf-b820c48ed115.
[    2.122647][  T395] systemd-cryptsetup[395]: Current policy digest does not match stored policy digest, cancelling TPM2 authentication attempt.
[    2.123598][  T395] systemd-cryptsetup[395]: No valid TPM2 token data found.

Please enter passphrase for disk cr_root::********
[   36.416691][  T395] systemd-cryptsetup[395]: Failed to activate with specified passphrase. (Passphrase incorrect?)

Please enter passphrase for disk cr_root::*********
[  OK  ] Finished Cryptography Setup for cr_root.
```

If you want a more specific message, like "PCR 8 measurement failed", then that would require a systemd upstream solution/RFE.

I agree that it would make sense to make these kind of decryption errors always visible in the initrd, I'll take a look.
Comment 2 Alexander Krupp 2023-11-10 09:43:01 UTC
I have been pondering the value of this for a while and arrive at the conclusion, that the value of such functionality depends on the person in front of the screen and very much on the particular circumstance.

SysAdmin: 

Case 1) SysAdmin has updated the boot process and expects a password to be asked for certain reasons. The feature may help here, because I could not determine any way to switch to another console while the password is prompted for. 

Case 2) system is compromised and will be able to show anything on screen

The feature does support case 1, but of course it does not help differentiating between cases 1 and 2. Any serious hack would try to emulate the output shown after a normal system update. 

User: 

should not necessarily know about the password anyway to avoid a user entering it on a compromised machine

---

One could also argue, that, psychologically, the addition of such messages may lead a SysAdmin to get used to it in a way, that he enters the password based on this particular message, under the false assumption that it is genuine, while in fact he should have verified the integrity of the system by other means. 

As the question for the password is the "red flag" in itself, it may be that not giving additional information is done so by design. 

I suggest to resolve this as INVALID or WONTFIX - in fact I will mark it such.