Re: [PATCH 0/1] KEYS: Measure keys in trusted keyring

[Lakshmi Ramasubramanian <nramas@linux.microsoft.com>]

On 9/19/19 10:12 AM, Mimi Zohar wrote:

Hi Mimi,

> On 9/1 I commented on this patch set from a technical perspective,
> saying: >
> IMA measures, appraises, and audits files based on policy[1].  If
> you're going to measure keys, all of the code should be within the IMA
> subdirectory.  The only code outside of the IMA subdirectory is either
> an LSM or IMA hook.  If an LSM hook already exists, use it.  If an LSM
> hook doesn't exist and the location is generic that other LSMs would
> be interested, define a new LSM hook, otherwise define a new IMA hook.

I am having trouble addressing the above feedback. Appreciate if you 
could provide guidance:

The key(s) in the trusted keys keyring (builtin, secondary, etc.) are 
added early in the kernel boot process. But IMA is initialized later.
If I have a LSM\IMA hook, that gets called when key(s) are added to the 
trusted keys keyring, I won't be able to invoke IMA on "key add" since 
IMA is not yet initialized.

Right now, I have the key measurement function in ima_init. I can gate 
that based on policy (similar to how Prakhar has done kexec_cmdline 
measurement) and follow the coding guidelines you have pointed to.
But it would still have to call keyring function to get the list of keys 
in the trusted keys keyring.

Are you fine if I take the above approach?

If not, could you please suggest a better way to handle it that meets 
the kernel layering guidelines?

Thanks,
  -lakshmi