All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	stephen.smalley.work@gmail.com, casey@schaufler-ca.com
Cc: tyhicks@linux.microsoft.com, tusharsu@linux.microsoft.com,
	sashal@kernel.org, jmorris@namei.org,
	linux-integrity@vger.kernel.org, selinux@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] IMA: Handle early boot data measurement
Date: Tue, 25 Aug 2020 10:55:46 -0700	[thread overview]
Message-ID: <52d2204b-5b6e-e13f-d0dd-192a776812bc@linux.microsoft.com> (raw)
In-Reply-To: <49f8a616d80344c539b512f8b83590ea281ee54d.camel@linux.ibm.com>

On 8/25/20 10:42 AM, Mimi Zohar wrote:

>>>
>>> Please limit the changes in this patch to renaming the functions and/or
>>> files.  For example, adding "measure_payload_hash" should be a separate
>>> patch, not hidden here.
>>>
>>
>> Thanks for the feedback Mimi.
>>
>> I'll split this into 2 patches:
>>
>> PATCH 1: Rename files + rename CONFIG
>> PATCH 2: Update IMA hook to utilize early boot data measurement.
> 
> I'm referring to introducing the "measure_payload_hash" flag.  I assume
> this is to indicate whether the buffer should be hashed or not.
> 
> Example 1: ima_alloc_key_entry() and ima_alloc_data_entry(0 comparison
>> -static struct ima_key_entry *ima_alloc_key_entry(struct key *keyring,
>> -                                                const void *payload,
>> -                                                size_t payload_len)
>> -{
> 
> 
>> +static struct ima_data_entry *ima_alloc_data_entry(const char *event_name,
>> +                                                  const void *payload,
>> +                                                  size_t payload_len,
>> +                                                  const char *event_data,
>> +                                                  enum ima_hooks func,
>> +                                                  bool measure_payload_hash)  <====
>> +{
> 
> Example 2:
> diff --git a/security/integrity/ima/ima_asymmetric_keys.c b/security/integrity/ima/ima_asymmetric_keys.c
> index a74095793936..65423754765f 100644
> --- a/security/integrity/ima/ima_asymmetric_keys.c
> +++ b/security/integrity/ima/ima_asymmetric_keys.c
> @@ -37,9 +37,10 @@ void ima_post_key_create_or_update(struct key *keyring, struct key *key,
>          if (!payload || (payload_len == 0))
>                  return;
>   
> -       if (ima_should_queue_key())
> -               queued = ima_queue_key(keyring, payload, payload_len);
> -
> +       if (ima_should_queue_data())
> +               queued = ima_queue_data(keyring->description, payload,
> +                                       payload_len, keyring->description,
> +                                       KEY_CHECK, false);   <===
>          if (queued)
>                  return;
> 
> But in general, as much as possible function and file name changes
> should be done independently of other changes.
> 
> thanks,

I agree - but in this case, Tushar's patch series on adding support for 
"Critical Data" measurement has already introduced 
"measure_payload_hash" flag. His patch updates 
"process_buffer_measurement()" to take this new flag and measure hash of 
the given data.

My patches extend that to queuing the early boot requests and processing 
them after a custom IMA policy is loaded.

If you still think "measure_payload_hash" flag should be introduced in 
the queuing change as a separate patch I'll split the patches further. 
Please let me know.

thanks,
  -lakshmi



  reply	other threads:[~2020-08-25 17:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21 23:12 [PATCH] IMA: Handle early boot data measurement Lakshmi Ramasubramanian
2020-08-25 15:40 ` Mimi Zohar
2020-08-25 15:46   ` Lakshmi Ramasubramanian
2020-08-25 17:42     ` Mimi Zohar
2020-08-25 17:55       ` Lakshmi Ramasubramanian [this message]
2020-08-25 18:03         ` Mimi Zohar
2020-08-25 19:35           ` Lakshmi Ramasubramanian
2020-08-25 19:43             ` Mimi Zohar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52d2204b-5b6e-e13f-d0dd-192a776812bc@linux.microsoft.com \
    --to=nramas@linux.microsoft.com \
    --cc=casey@schaufler-ca.com \
    --cc=jmorris@namei.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=tusharsu@linux.microsoft.com \
    --cc=tyhicks@linux.microsoft.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.