bootflags: /dev/mapper/lvmvolume-encrypted ro rootflags=i_version dolvm ima_appraise=enforce ima_policy=tcb ima_policy=appraise_tcb crypt_root=/dev/sda3 real_root=/dev/mapper/lvmvolume-encrypted resume=/dev/mapper/lvmvolume-swap clocksource=hpet enforcing=0 The problem is the hardware TPM PCR 10 values are never the same upon reboots so you are not able to take advantage of the IMA (Integrity Measurement Architecture.) PCR register extend and verification. Full problem explained: The bios and kernel are in charge of extending PCR 0-9 which PCR 0-9 is always the same do to the fact the bios,mbr,kernel are always loaded/extended in same order and contain the same hash. The kernel and initramfs is the last thing extended into PCR 9. The problem comes about when extending PCR 10 (all user lever access files). The problem comes about when the kernel executes the initrc process. I have narrowed the problem in the initrc process when the initrc process mounts root it runs initscripts these scripts access (text, executable, shared libs, etc..) files. I have checked the actual files loaded by initrc every boot are the same files and exact hash its just that the files load/access order are not the same at every boot which affects PCR 10 value Not sure but I have thought of a possible cause to the problem. Maybe initrc is running some actions multi threaded and based on random completion the files are being extended to PCR 10 randomly instead of in the same order every time. The other problem is "IMA + EVM + SELINUX" will not boot together you either have to choose one or the other. Either IMA or SELINUX alone but if both are enabled with EVM using TPM hardware to store keys system will not boot past initrc. Cant seem to find out wht is going on.
PCR10 is not useful for sealing. Its value may vary from boot to boot, even with the same content because the PCR extension function is neither commutative nor associative, so the files are opened in a different order, the hash is different. Instead PCR10 can be used for attestation: The attesting party requests the log and a quote of PCR10. The attesting party performs the same PCR extension function on hashes in the log, and if it arrives to the same result of the quotes PCR10, it known the log is genuine. The attesting party can then compare whichever hashes in the log it desires with a "known good" list. Typically, it would then make a authorization decision based on it.
Thanks for the speedy reply I have done some more reading and now I see. I would calculate the hashes on files in list from "/sys/kernel/security/ima/ascii_runtime_measurements" (which includes boot_aggregate and files loaded after kernel) in the same order and compare it with "/sys/kernel/security/ima/ascii_runtime_measurements" to attest the system. What app/tool could be used to do the above operation?
This would be better discussed in the Gentoo Forums (https://forums.gentoo.org/) since its not a bug. Create a new topic in the Network & Security forums and I'll answer there.
It is sad to read that you have problems with the software. The situation seems to be a bit more complicate and requires some analysis. We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3]. I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4]. Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product. [1] https://www.gentoo.org/get-involved/irc-channels/ [2] https://forums.gentoo.org/ [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html [4] https://www.gentoo.org/support/
*** Bug 777300 has been marked as a duplicate of this bug. ***
