[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1571853139.5104.154.camel@linux.ibm.com>
Date: Wed, 23 Oct 2019 13:52:19 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
dhowells@...hat.com, casey@...aufler-ca.com, sashal@...nel.org,
jamorris@...ux.microsoft.com,
linux-security-module@...r.kernel.org,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
keyrings@...r.kernel.org
Subject: Re: [PATCH v1 5/6] KEYS: measure queued keys
On Wed, 2019-10-23 at 10:34 -0700, Lakshmi Ramasubramanian wrote:
> On 10/23/19 6:23 AM, Mimi Zohar wrote:
>
> > The ordering of this patch set is awkward. It should first introduce
> > a generic method for measuring keys based on the keyring. Then add
> > the additional support needed for the specific builtin_trusted_keys
> > keyring usecase.
>
> Would the following ordering of the patch set be acceptable:
>
> => PATCH 0/5: Cover letter
>
> => PATCH 1/5: Define the enum "hook(BUILTIN_TRUSTED_KEYS)" in ima.h
>
> => PATCH 2/5: Define ima hook
> This will initially do nothing if ima is not yet
> initialized.
> Call process_buffer_measurement() if ima is initialized.
>
> => PATCH 3/5: key_create_or_update change and the call to ima hook
>
> => PATCH 4/5: Queue\De-Queue of key measurement requests.
> Enable queuing of key in the ima hook if ima is not
> initialized.
>
> => PATCH 5/5: ima policy to enable measurement of keys which will
> enable end-to-end working of this feature.
The first patches need to introduce the generic concept of measuring
keys based on policy. Only afterwards would you add any builtin
trusted keyring specific code.
Mimi
Powered by blists - more mailing lists