|
Bugzilla – Full Text Bug Listing |
| Summary: | Aeon RC3 (20240726) automatically unlocks partition even if kernel cmdline is modified | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Aeon | Reporter: | Philipp Nordhus <philipp> |
| Component: | Installation | Assignee: | Richard Brown <rbrown> |
| Status: | IN_PROGRESS --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | aplanas, rbrown, tim |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Philipp Nordhus
2024-07-29 13:40:33 UTC
Alberto, can you explain why Aeon systems are showing tpm2-pcrlock: false? and an invalid list of tpm2-hash-pcrs? They have valid predictions according to sdbootutil -v update-predictions They are enrolled during systemd-cryptenroll <device> --tpm2-device auto just as the reporter does here: https://github.com/sysrich/tik/blob/main/usr/lib/tik/modules/post/15-encrypt#L205 No problem Alberto - figured out what I goofed Managed to enrol things in the wrong order so during installation I make the policy after enrolling with the temporary PCR7 hash Boy do I feel stupid now Thanks Philipp for the awesome bug report - here's the plan to fix it Aeon users won't need to do anything as I'm using this bug as the excuse to start work on 'aeon-check' (Aeon's internal tooling to correct known issues that cant otherwise be addressed..just like this bug) Long term goal is to use containers and other fancy stuff But this one is easy to all do locally aeon-check is now on github.com/AeonDesktop/aeon-check It's packaged It's under testing and will be submitted to Aeon as soon as I'm happy it works reliably My initial test is looking great - and it wont let me change the cmdline now :) Then I'll go back and fix the installer to stop doing the stupid..but my priority is the existing users because I promised everyone no reinstalls now :) Won't close this bug until both aeon-check and the fixes to tik are submitted to Factory *** Bug 1228411 has been marked as a duplicate of this bug. *** This is an autogenerated message for OBS integration: This bug (1228416) was mentioned in https://build.opensuse.org/request/show/1190481 Factory / patterns-aeon (In reply to Philipp Nordhus from comment #0) > I then checked the LUKS header with "cryptsetup luksDump <device>" which > reported the following: > tpm2-hash-pcrs: 7 > tpm2-pcrlock: false > But pcrlock has to be enabled to prevent tampering of boot config on Aeon, > correct? Correct. During installation this needs to be done. > I then manually re-enrolled with > systemd-cryptenroll <device> --wipe-slot 2 > systemd-cryptenroll <device> --tpm2-device auto > > Afterwards, luksDump reports this: > tpm2-hash-pcrs: <empty> > tpm2-pcrlock: true The means that the pcrlock file was present and cryptenroll enrolled it. > which is what I would expect. If I now try to modify the cmdline on boot, it > correctly asks for the recovery key. > > I've reinstalled 3 times, always with the same behavior. I don't have a > tik.log on the stick after installation, is it not saved if the installation > finished successfully? Seems that the problem is in the installer (In reply to Richard Brown from comment #2) > No problem Alberto - figured out what I goofed > > Managed to enrol things in the wrong order so during installation I make the > policy after enrolling with the temporary PCR7 hash There is now a new "sdbootutil enroll" command that can help here. One example of use is this: https://github.com/openSUSE/disk-encryption-tool/pull/20 aeon-check will be released in snapshot 20240731 or later and will automatically fix the misconfiguration on existing machines Please reopen if the issue occurs in systems newer than that tik 1.2.3 submitted to Factory, should be in snapshot 20240801 or later, and prevent this issue from occurring in the first place |