Re: [PATCH v10 0/8] Enroll kernel keys thru MOK
From: Jarkko Sakkinen <jarkko@kernel.org>
Date: 2022-02-22 12:26:15
Also in:
keyrings, linux-efi, lkml
On Tue, Feb 22, 2022 at 06:59:25AM -0500, Mimi Zohar wrote:
On Sun, 2022-02-20 at 20:00 +0100, Jarkko Sakkinen wrote:quoted
On Wed, Jan 26, 2022 at 05:06:09PM -0500, Mimi Zohar wrote:quoted
quoted
quoted
Mimi brought up that we need a MAINTAINERS update for this and also .platform. We have these: - KEYS/KEYRINGS - CERTIFICATE HANDLING I would put them under KEYRINGS for now and would not consider further subdivision for the moment.IMA has dependencies on the platform_certs/ and now on the new .machine keyring. Just adding "F: security/integrity/platform_certs/" to the KEYS/KEYRINGS record, ignores that dependency. The discussion wouldn't even be on the linux-integrity mailing list. Existing requirement: - The keys on the .platform keyring are limited to verifying the kexec image. New requirements based on Eric Snowbergs' patch set: - When IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled, the MOK keys will not be loaded directly onto the .machine keyring or indirectly onto the .secondary_trusted_keys keyring. - Only when a new IMA Kconfig explicitly allows the keys on the .machine keyrings, will the CA keys stored in MOK be loaded onto the .machine keyring. Unfortunately I don't think there is any choice, but to define a new MAINTAINERS entry. Perhaps something along the lines of: KEYS/KEYRINGS_INTEGRITY M: Jarkko Sakkinen [off-list ref] M: Mimi Zohar [off-list ref] L: keyrings@vger.kernel.org L: linux-integrity@vger.kernel.org F: security/integrity/platform_certsThis would work for me.Thanks, Jarkko. Are you planning on upstreaming this change, as you previously said, or would you prefer I do it? thanks, Mimi
This is the problem I'm encountering: https://lore.kernel.org/keyrings/YhLNYxBTbKW62vtC@iki.fi/ (local) BR, Jarkko