linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	dhowells@redhat.com, matthewgarrett@google.com,
	sashal@kernel.org, jamorris@linux.microsoft.com,
	linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org
Cc: prsriva@linux.microsoft.com
Subject: Re: [PATCH v3 3/9] KEYS: Added KEYRING_CHECK policy for key measurement
Date: Thu, 31 Oct 2019 08:10:51 -0400	[thread overview]
Message-ID: <1572523851.5028.45.camel@linux.ibm.com> (raw)
In-Reply-To: <20191031011910.2574-4-nramas@linux.microsoft.com>

On Wed, 2019-10-30 at 18:19 -0700, Lakshmi Ramasubramanian wrote:
> An IMA policy to manage measurement of keys is not supported.
> A new IMA policy is needed to manage the measurement of keys.
> A policy option is also needed to allow measurement of keys
> linked to a given set of keyrings only.
> 
> This patch defines KEYRING_CHECK and keyrings in IMA policy
> for this purpose. 

"KEYRING_CHECK" and "keyrings" are not related.   One is a "func"
name, while the other is an IMA policy option.  This should be broken
up into two different patches.  When defining a new policy option, the
only code in that patch should be the new policy option.

> 
> KEYRING_CHECK can be added in the IMA policy to measure keys.
> keyrings can be, optionally, set to only measure keys
> added or updated to a given set of keyrings. If keyrings is not
> specified for KEYRING_CHECK, keys added or updated in
> all keyrings are measured.
> 
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> ---
>  Documentation/ABI/testing/ima_policy | 15 +++++++++++++++
>  security/integrity/ima/ima.h         |  1 +
>  security/integrity/ima/ima_main.c    |  2 +-
>  security/integrity/ima/ima_policy.c  |  2 +-
>  security/integrity/ima/ima_queue.c   |  2 +-
>  5 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
> index fc376a323908..757faf1a1a27 100644
> --- a/Documentation/ABI/testing/ima_policy
> +++ b/Documentation/ABI/testing/ima_policy
> @@ -25,10 +25,12 @@ Description:
>  			lsm:	[[subj_user=] [subj_role=] [subj_type=]
>  				 [obj_user=] [obj_role=] [obj_type=]]
>  			option:	[[appraise_type=]] [template=] [permit_directio]
> +				[keyrings=]
>  		base: 	func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
>  				[FIRMWARE_CHECK]
>  				[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
>  				[KEXEC_CMDLINE]
> +				[KEYRING_CHECK]

This patch is measuring keys, not keyrings.


>  			mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
>  			       [[^]MAY_EXEC]
>  			fsmagic:= hex value
> @@ -38,6 +40,9 @@ Description:
>  			fowner:= decimal value
>  		lsm:  	are LSM specific
>  		option:	appraise_type:= [imasig]
> +			keyrings: = list of keyrings to measure
> +			(eg, .builtin_trusted_keys|.ima). Only valid
> +			when action is "measure" and func is KEYRING_CHECK.
>  			template:= name of a defined IMA template type
>  			(eg, ima-ng). Only valid when action is "measure".
>  			pcr:= decimal value
> @@ -105,3 +110,13 @@ Description:
>  
>  			measure func=KEXEC_KERNEL_CHECK pcr=4
>  			measure func=KEXEC_INITRAMFS_CHECK pcr=5
> +
> +		Example of measure rules using KEYRING_CHECK
> +			To measure keys added to
> +			.builtin_trusted_keys or .ima keyring:
> +
> +			measure func=KEYRING_CHECK keyrings=.builtin_trusted_keys|.ima
> +
> +			To measure keys added to all keyrings:
> +
> +			measure func=KEYRING_CHECK

The patch that introduces the new IMA "func" should document the new
IMA "func".  The patch that introduces the new "keyring=" policy
option should document the new IMA policy option.  Examples could be
included in each of the patches descriptions.


> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index b9600070e415..12e9ec6847b5 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -191,6 +191,7 @@ static inline unsigned long ima_hash_key(u8 *digest)
>  	hook(KEXEC_INITRAMFS_CHECK)	\
>  	hook(POLICY_CHECK)		\
>  	hook(KEXEC_CMDLINE)		\
> +	hook(KEYRING_CHECK)		\
>  	hook(MAX_CHECK)
>  #define __ima_hook_enumify(ENUM)	ENUM,
>  
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 18e1bc105be7..72ae0878ec5d 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -718,7 +718,7 @@ void ima_post_key_create_or_update(struct key *keyring, struct key *key,
>  	pk = key->payload.data[asym_crypto];
>  	process_buffer_measurement(pk->key, pk->keylen,
>  				   keyring->description,
> -				   NONE, 0);
> +				   KEYRING_CHECK, 0);
>  }
>  
>  static int __init init_ima(void)
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index 6df7f641ff66..0cc49f2d5233 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -370,7 +370,7 @@ static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode,
>  {
>  	int i;
>  
> -	if (func == KEXEC_CMDLINE) {
> +	if ((func == KEXEC_CMDLINE) || (func == KEYRING_CHECK)) {
>  		if ((rule->flags & IMA_FUNC) && (rule->func == func))
>  			return true;
>  		return false;
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index f2503f10abf4..5625381c5a97 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -317,7 +317,7 @@ void ima_measure_queued_keys(void)
>  		process_buffer_measurement(entry->public_key,
>  					   entry->public_key_len,
>  					   entry->keyring_name,
> -					   NONE, 0);
> +					   KEYRING_CHECK, 0);

Changing a newly defined call should be an indication that the patch
ordering is wrong.  If the new "func" was defined prior or with the
new IMA hook, then this change wouldn't be needed.

Mimi


>  		list_del(&entry->list);
>  		ima_free_measure_key_entry(entry);
>  	}


  reply	other threads:[~2019-10-31 12:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31  1:19 [PATCH v3 0/9] KEYS: Measure keys when they are created or updated Lakshmi Ramasubramanian
2019-10-31  1:19 ` [PATCH v3 1/9] KEYS: Defined an IMA hook to measure keys on key create or update Lakshmi Ramasubramanian
2019-10-31  9:10   ` Sasha Levin
2019-10-31 15:27     ` Lakshmi Ramasubramanian
2019-10-31 15:36       ` Sasha Levin
2019-10-31 12:10   ` Mimi Zohar
2019-10-31 15:08     ` Lakshmi Ramasubramanian
2019-10-31 15:27       ` Sasha Levin
2019-10-31 15:37         ` Mimi Zohar
2019-10-31 15:42           ` Lakshmi Ramasubramanian
2019-10-31  1:19 ` [PATCH v3 2/9] KEYS: Defined functions to queue and dequeue keys for measurement Lakshmi Ramasubramanian
2019-10-31 12:10   ` Mimi Zohar
2019-10-31 15:09     ` Lakshmi Ramasubramanian
2019-10-31  1:19 ` [PATCH v3 3/9] KEYS: Added KEYRING_CHECK policy for key measurement Lakshmi Ramasubramanian
2019-10-31 12:10   ` Mimi Zohar [this message]
2019-10-31  1:19 ` [PATCH v3 4/9] KEYS: Updated IMA policy functions for handling " Lakshmi Ramasubramanian
2019-10-31 12:10   ` Mimi Zohar
2019-10-31  1:19 ` [PATCH v3 5/9] KEYS: Updated ima_get_action() to return keyrings if specified in the policy Lakshmi Ramasubramanian
2019-10-31  1:19 ` [PATCH v3 6/9] KEYS: Measure key if the IMA policy allows measurement for the given keyring Lakshmi Ramasubramanian
2019-10-31  1:19 ` [PATCH v3 7/9] KEYS: Queue key for measurement if IMA is not yet initialized. Measure queued keys when IMA initialization is completed Lakshmi Ramasubramanian
2019-10-31  1:19 ` [PATCH v3 8/9] KEYS: Added a boolean flag for IMA initialization status Lakshmi Ramasubramanian
2019-10-31  1:19 ` [PATCH v3 9/9] 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=1572523851.5028.45.camel@linux.ibm.com \
    --to=zohar@linux.ibm.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=nramas@linux.microsoft.com \
    --cc=prsriva@linux.microsoft.com \
    --cc=sashal@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).