Hi, at SUSE we implemented an integration test for our enterprise kernels that checks the functionality of various IMA/EVM related features like IMA appraisal with digital signatures. To do this a custom CA certificate is enrolled as a MOK certificate in the system. The according public key is then loaded into the .ima kernel keyring to be used for verification of security.ima signatures. With a recent update we did from kernel version 4.12 to version 5.3 a regression in this integration test was reported by our QA team. As it turned out the reason is kernel option INTEGRITY_PLATFORM_KEYRING=y, which is the default setting our kernel engineers took over. With this option enabled a couple of platform certificates are no longer loaded into the .secondary_trusted_keys keyring but into the new .platform keyring. And IMA only uses those keys to verify things like kexec any more. The certificate we enrolled as MOK in the system is now also part for the .platform keyring, causing us to be unable to load the required public key into the .ima keyring. I was able to still get things to work by building my own custom kernel with the custom CA being built into the kernel which is a lot of more effort, however, and a scenario we can't easily support for our customers. I can understand the reasoning of that new option, that trusting arbitrary platform certificates shipped with the hardware might not be a good idea. I wonder, however, whether moving these certificates from .secondary_trusted_keys to .platform doesn't also affect other components than just IMA? I would be interested in your view on this and any advice. Cheers Matthias -- Matthias Gerstner <matthias.gerstner@xxxxxxx> Dipl.-Wirtsch.-Inf. (FH), Security Engineer https://www.suse.com/security Phone: +49 911 740 53 290 GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description: PGP signature
