Messages in this thread | | | Subject | Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring | From | "Mark D. Baushke" <> | Date | Mon, 11 Jan 2016 18:25:55 -0800 |
| |
David Howells <dhowells@redhat.com> writes:
> Signing keys go in .ima only?
Yes, that is the current intent... it is not yet clear to me if it should also be in play for any .evm keys or not.
> It still doesn't clarify entirely why .ima_mok exists separately from > .system_keyring from a technical point of view.
IMA is an optional subsystem. Having a keyring for it to use as needed seems more flexible to me than getting all of the .system_keyring stakeholders to agree to any new semantics that might be needed.
Rules on how .system_keyring mature and are managed would seem to be something that has multiple stakeholders.
If a .ima_mok exists, then we can partition the rules associated with .ima_mok additions and deletions to being a chain of trust that is used to authorize a given .ima key entry to be permitted to be used and not fight with other .system_keyring semantics.
For example,
keyctl clear %:.sysmtem_keyring
locks out adding keys to the primary keystore. That may be exactly the correct thing to do to stop adding new LKM keys. While still allowing new keys to be added to the .ima_mok that can in turn only authorize the addition/deletion of .ima keys.
With regard to a .blacklist keyring type, I have no objections to sharing a blacklist accross the system.
Sometime soon I need to hunt down the [RFC PATCH 14/15] KEYS:... and figure out how the restriction functions are supposed to work.
I appreciate the time you have taken to write a response to my message.
I hope that I have managed to provide you have a better understanding of the goals of a multi-tenant IMA system...
Thanks, -- Mark
| |