All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	dhowells@redhat.com, matthewgarrett@google.com,
	sashal@kernel.org, jamorris@linux.microsoft.com,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 01/10] IMA: Defined an IMA hook to measure keys on key create or update
Date: Thu, 07 Nov 2019 21:12:31 +0000	[thread overview]
Message-ID: <f45593ae-823e-6d61-d14c-20726bd8cacc@linux.microsoft.com> (raw)
In-Reply-To: <1573159988.5028.400.camel@linux.ibm.com>

On 11/7/19 12:53 PM, Mimi Zohar wrote:

>>
>> The measurement decision is not based on whether the keyring is a
>> trusted one or an untrusted one. As long as the IMA policy allows
>> (through the "keyrings=" option) the key will be measured.
> 
> We should be able to measure all keys being loaded onto any keyring or
> onto a specific "keyring=".   This shouldn't be any different than any
> other policy rule.  Once you have this basic feature working, you
> would address loading keys during early boot.
Perfect - that's exactly how I have implemented it right now. Will 
continue to test it.

>> Do you want only trusted keyrings to be allowed in the measurement?
>> In my opinion, that decision should be deferred to whoever is setting up
>> the IMA policy.
> 
> Right, but it shouldn't be limited to just "trusted" keyrings.  This
> way you can first test loading keys onto any keyring.
Thank you.

> Queuing the keys should be independent of measuring the keys.
>   Initially you would start with just measuring the key.  From a high
> level it would look like:
> 
>      ima_post_key_create_or_update(...)
>      {
>         "measure key based on
>      policy(key, keyring, ...)"
>      }
> 
> This requires the IMA "keyring=" policy option support be defined
> first.
> 
> Subsequently you would add key queuing support, and then update
> ima_post_key_create_or_update().  It would look like:
> 
>          ima_post_key_create_or_update(...)
>          {
>              if (custom policy is loaded)
>                 "measure key based on policy(key, keyring, ...)"
>              else
>                  "queue key(key, keyring)"
>          }
> 
> Mimi

Yes - I have the above change working. Will continue testing.

thanks,
  -lakshmi

WARNING: multiple messages have this Message-ID (diff)
From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	dhowells@redhat.com, matthewgarrett@google.com,
	sashal@kernel.org, jamorris@linux.microsoft.com,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 01/10] IMA: Defined an IMA hook to measure keys on key create or update
Date: Thu, 7 Nov 2019 13:12:31 -0800	[thread overview]
Message-ID: <f45593ae-823e-6d61-d14c-20726bd8cacc@linux.microsoft.com> (raw)
In-Reply-To: <1573159988.5028.400.camel@linux.ibm.com>

On 11/7/19 12:53 PM, Mimi Zohar wrote:

>>
>> The measurement decision is not based on whether the keyring is a
>> trusted one or an untrusted one. As long as the IMA policy allows
>> (through the "keyrings=" option) the key will be measured.
> 
> We should be able to measure all keys being loaded onto any keyring or
> onto a specific "keyring=".   This shouldn't be any different than any
> other policy rule.  Once you have this basic feature working, you
> would address loading keys during early boot.
Perfect - that's exactly how I have implemented it right now. Will 
continue to test it.

>> Do you want only trusted keyrings to be allowed in the measurement?
>> In my opinion, that decision should be deferred to whoever is setting up
>> the IMA policy.
> 
> Right, but it shouldn't be limited to just "trusted" keyrings.  This
> way you can first test loading keys onto any keyring.
Thank you.

> Queuing the keys should be independent of measuring the keys.
>   Initially you would start with just measuring the key.  From a high
> level it would look like:
> 
>      ima_post_key_create_or_update(...)
>      {
>         "measure key based on
>      policy(key, keyring, ...)"
>      }
> 
> This requires the IMA "keyring=" policy option support be defined
> first.
> 
> Subsequently you would add key queuing support, and then update
> ima_post_key_create_or_update().  It would look like:
> 
>          ima_post_key_create_or_update(...)
>          {
>              if (custom policy is loaded)
>                 "measure key based on policy(key, keyring, ...)"
>              else
>                  "queue key(key, keyring)"
>          }
> 
> Mimi

Yes - I have the above change working. Will continue testing.

thanks,
  -lakshmi

  reply	other threads:[~2019-11-07 21:12 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 19:01 [PATCH v4 0/10] KEYS: Measure keys when they are created or updated Lakshmi Ramasubramanian
2019-11-06 19:01 ` Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 01/10] IMA: Defined an IMA hook to measure keys on key create or update Lakshmi Ramasubramanian
2019-11-06 19:01   ` Lakshmi Ramasubramanian
2019-11-06 22:43   ` Mimi Zohar
2019-11-06 22:43     ` Mimi Zohar
2019-11-07  0:21     ` Lakshmi Ramasubramanian
2019-11-07  0:21       ` Lakshmi Ramasubramanian
2019-11-07  3:40       ` Mimi Zohar
2019-11-07  3:40         ` Mimi Zohar
2019-11-07 18:42         ` Lakshmi Ramasubramanian
2019-11-07 18:42           ` Lakshmi Ramasubramanian
2019-11-07 20:53           ` Mimi Zohar
2019-11-07 20:53             ` Mimi Zohar
2019-11-07 21:12             ` Lakshmi Ramasubramanian [this message]
2019-11-07 21:12               ` Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 02/10] IMA: Added KEYRING_CHECK func in IMA policy to measure keys Lakshmi Ramasubramanian
2019-11-06 19:01   ` Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 03/10] IMA: Added keyrings= option in IMA policy to only measure keys added to the specifi Lakshmi Ramasubramanian
2019-11-06 19:01   ` [PATCH v4 03/10] IMA: Added keyrings= option in IMA policy to only measure keys added to the specified keyrings Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 04/10] IMA: Read keyrings= option from the IMA policy into ima_rule_entry Lakshmi Ramasubramanian
2019-11-06 19:01   ` Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 05/10] IMA: Updated IMA policy functions to return keyrings option read from the policy Lakshmi Ramasubramanian
2019-11-06 19:01   ` Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 06/10] IMA: Measure key if the IMA policy allows measurement for the keyring to which the Lakshmi Ramasubramanian
2019-11-06 19:01   ` [PATCH v4 06/10] IMA: Measure key if the IMA policy allows measurement for the keyring to which the key is linked to Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 07/10] IMA: Added a boolean flag to track IMA initialization status Lakshmi Ramasubramanian
2019-11-06 19:01   ` Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 08/10] IMA: Defined functions to queue and dequeue keys for measurement Lakshmi Ramasubramanian
2019-11-06 19:01   ` Lakshmi Ramasubramanian
2019-11-06 22:44   ` Mimi Zohar
2019-11-06 22:44     ` Mimi Zohar
2019-11-06 23:52     ` Lakshmi Ramasubramanian
2019-11-06 23:52       ` Lakshmi Ramasubramanian
2019-11-07  2:20     ` Lakshmi Ramasubramanian
2019-11-07  2:20       ` Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 09/10] IMA: Call queue and dequeue functions to measure keys Lakshmi Ramasubramanian
2019-11-06 19:01   ` Lakshmi Ramasubramanian
2019-11-06 19:01 ` [PATCH v4 10/10] KEYS: Call the IMA hook to measure key when a new key is created or an existing key Lakshmi Ramasubramanian
2019-11-06 19:01   ` [PATCH v4 10/10] KEYS: Call the IMA hook to measure key when a new key is created or an existing key is updated Lakshmi Ramasubramanian

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=f45593ae-823e-6d61-d14c-20726bd8cacc@linux.microsoft.com \
    --to=nramas@linux.microsoft.com \
    --cc=dhowells@redhat.com \
    --cc=jamorris@linux.microsoft.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthewgarrett@google.com \
    --cc=sashal@kernel.org \
    --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.