All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]
Date: Mon, 07 Mar 2016 21:26:33 -0500	[thread overview]
Message-ID: <1457403993.5321.33.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160304150149.17121.31855.stgit@warthog.procyon.org.uk>

On Fri, 2016-03-04 at 15:01 +0000, David Howells wrote:
> Provide a config option (IMA_PERMIT_ADD_TO_IMA_KEYRINGS) that, when
> enabled, allows keys to be added to the IMA keyrings by userspace - with
> the restriction that each must be signed by a key in the system trusted
> keyrings.

Here is an example of using the term "system trusted keyrings", which
the previous patch removes.

> EPERM will be returned if this option is disabled, ENOKEY will be returned if
> no authoritative key can be found and EKEYREJECTED will be returned if the
> signature doesn't match.  Other errors such as ENOPKG may also be returned.
> 
> If this new option is enabled, the builtin system keyring is searched, as is
> the secondary system keyring if that is also enabled.  Intermediate keys
> between the builtin system keyring and the key being added can be added to
> the secondary keyring (which replaces .ima_mok) to form a trust chain -
> provided they are also validly signed by a key in one of the trusted keyrings.

Only certificates signed by a key on the system keyring were added to
the IMA keyring, unless IMA_MOK_KEYRING was configured.  Then, the
certificate could be signed by a either a key on the system or ima_mok
keyrings.  To replicate this behavior, the default behavior should be to
only permit certificates signed by a key on the builtin keyring, unless
this new Kconfig is enabled.  Only then, permit certificates signed by a
key on either the builtin or secondary keyrings to be added to the IMA
keyring.

Mimi


> The .ima_mok keyring is removed.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
> 
>  include/keys/system_keyring.h    |    9 ---------
>  security/integrity/digsig.c      |   31 +++++--------------------------
>  security/integrity/ima/Kconfig   |   36 ++++++++++++++++++++++++------------
>  security/integrity/ima/ima_mok.c |   12 ++----------
>  4 files changed, 31 insertions(+), 57 deletions(-)
> 
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index c6c05f1513f5..0764a8c1c131 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -29,22 +29,13 @@ extern int restrict_link_by_builtin_trusted(struct key *keyring,
>  #endif
> 
>  #ifdef CONFIG_IMA_MOK_KEYRING
> -extern struct key *ima_mok_keyring;
>  extern struct key *ima_blacklist_keyring;
> 
> -static inline struct key *get_ima_mok_keyring(void)
> -{
> -	return ima_mok_keyring;
> -}
>  static inline struct key *get_ima_blacklist_keyring(void)
>  {
>  	return ima_blacklist_keyring;
>  }
>  #else
> -static inline struct key *get_ima_mok_keyring(void)
> -{
> -	return NULL;
> -}
>  static inline struct key *get_ima_blacklist_keyring(void)
>  {
>  	return NULL;
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index ac2d39232567..aef3ac7be868 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -42,32 +42,10 @@ static bool init_keyring __initdata = true;
>  static bool init_keyring __initdata;
>  #endif
> 
> -#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING
> -/*
> - * Restrict the addition of keys into the IMA keyring.
> - *
> - * Any key that needs to go in .ima keyring must be signed by CA in
> - * either .system or .ima_mok keyrings.
> - */
> -static int restrict_link_by_ima_mok(struct key *keyring,
> -				    const struct key_type *type,
> -				    const union key_payload *payload)
> -{
> -	int ret;
> -
> -	ret = restrict_link_by_system_trusted(keyring, type, payload);
> -	if (ret != -ENOKEY)
> -		return ret;
> -
> -	return restrict_link_by_signature(get_ima_mok_keyring(),
> -					  type, payload);
> -}
> +#ifdef CONFIG_IMA_PERMIT_ADD_TO_IMA_KEYRINGS
> +#define restrict_link_to_ima restrict_link_by_system_trusted
>  #else
> -/*
> - * If there's no system trusted keyring, then keys cannot be loaded into
> - * .ima_mok and added keys cannot be marked trusted.
> - */
> -#define restrict_link_by_ima_mok restrict_link_reject
> +#define restrict_link_to_ima restrict_link_reject
>  #endif
> 
>  int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
> @@ -114,7 +92,8 @@ int __init integrity_init_keyring(const unsigned int id)
>  				     KEY_USR_VIEW | KEY_USR_READ |
>  				     KEY_USR_WRITE | KEY_USR_SEARCH),
>  				    KEY_ALLOC_NOT_IN_QUOTA,
> -				    restrict_link_by_ima_mok, NULL);
> +				    restrict_link_to_ima,
> +				    NULL);
>  	if (IS_ERR(keyring[id])) {
>  		err = PTR_ERR(keyring[id]);
>  		pr_info("Can't allocate %s keyring (%d)\n",
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index e54a8a8dae94..890e8aa8ccb4 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -155,23 +155,35 @@ config IMA_TRUSTED_KEYRING
> 
>  	   This option is deprecated in favor of INTEGRITY_TRUSTED_KEYRING
> 
> +config IMA_PERMIT_ADD_TO_IMA_KEYRINGS
> +	bool "Allow keys to be added to the ima keyrings, with restrictions"
> +	depends on IMA_APPRAISE
> +	depends on SYSTEM_TRUSTED_KEYRING
> +	select INTEGRITY_TRUSTED_KEYRING
> +	default n
> +	help
> +	  This option permits keys to be added to the ima keyrings using
> +	  add_key() or KEYCTL_LINK - with the restriction that the key must be
> +	  validly signed by a key in one of the system trusted keyrings.
> +
> +	  Intermediate keys between those the kernel has compiled in and the
> +	  keys to be added may be added to the system secondary keyring if that
> +	  is enabled - provided those are validly signed by a key in the system
> +	  trusted keyrings.
> +
> +	  If this is not set, attempts to add to the ima keyrings will be
> +	  rejected with EPERM.
> +
>  config IMA_MOK_KEYRING
> -	bool "Create IMA machine owner keys (MOK) and blacklist keyrings"
> +	bool "Create IMA machine owner blacklist keyrings"
>  	depends on SYSTEM_TRUSTED_KEYRING
>  	depends on IMA_TRUSTED_KEYRING
>  	default n
>  	help
> -	   This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
> -	   intermediate keyring that sits between .system and .ima keyrings,
> -	   effectively forming a simple CA hierarchy.  To successfully import a
> -	   key into .ima_mok it must be signed by a key which CA is in .system
> -	   keyring.  On turn any key that needs to go in .ima keyring must be
> -	   signed by CA in either .system or .ima_mok keyrings. IMA MOK is empty
> -	   at kernel boot.
> -
> -	   IMA blacklist keyring contains all revoked IMA keys.  It is consulted
> -	   before any other keyring.  If the search is successful the requested
> -	   operation is rejected and error is returned to the caller.
> +	   This option creates IMA blacklist keyring.  This contains all
> +	   revoked IMA keys.  It is consulted before any other keyring.  If the
> +	   search is successful the requested operation is rejected and error
> +	   is returned to the caller.
> 
>  config IMA_LOAD_X509
>  	bool "Load X509 certificate onto the '.ima' trusted keyring"
> diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
> index be0da013622c..031d65a91297 100644
> --- a/security/integrity/ima/ima_mok.c
> +++ b/security/integrity/ima/ima_mok.c
> @@ -28,15 +28,7 @@ struct key *ima_blacklist_keyring;
>   */
>  __init int ima_mok_init(void)
>  {
> -	pr_notice("Allocating IMA MOK and blacklist keyrings.\n");
> -
> -	ima_mok_keyring = keyring_alloc(".ima_mok",
> -			      KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
> -			      (KEY_POS_ALL & ~KEY_POS_SETATTR) |
> -			      KEY_USR_VIEW | KEY_USR_READ |
> -			      KEY_USR_WRITE | KEY_USR_SEARCH,
> -			      KEY_ALLOC_NOT_IN_QUOTA,
> -			      restrict_link_by_system_trusted, NULL);
> +	pr_notice("Allocating IMA blacklist keyrings.\n");
> 
>  	ima_blacklist_keyring = keyring_alloc(".ima_blacklist",
>  				KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
> @@ -46,7 +38,7 @@ __init int ima_mok_init(void)
>  				KEY_ALLOC_NOT_IN_QUOTA,
>  				restrict_link_by_system_trusted, NULL);
> 
> -	if (IS_ERR(ima_mok_keyring) || IS_ERR(ima_blacklist_keyring))
> +	if (IS_ERR(ima_blacklist_keyring))
>  		panic("Can't allocate IMA MOK or blacklist keyrings.");
> 
>  	set_bit(KEY_FLAG_KEEP, &ima_blacklist_keyring->flags);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2016-03-08  2:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 15:00 [RFC PATCH 00/12] KEYS: Restrict additions to 'trusted' keyrings [ver #2] David Howells
2016-03-04 15:00 ` [RFC PATCH 01/12] KEYS: Generalise system_verify_data() to provide access to internal content " David Howells
2016-03-04 15:00 ` [RFC PATCH 02/12] PKCS#7: Make trust determination dependent on contents of trust keyring " David Howells
2016-03-04 15:00 ` [RFC PATCH 03/12] KEYS: Add a facility to restrict new links into a " David Howells
2016-03-04 15:00 ` [RFC PATCH 04/12] KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c " David Howells
2016-03-04 15:00 ` [RFC PATCH 05/12] KEYS: Generalise x509_request_asymmetric_key() " David Howells
2016-03-04 15:01 ` [RFC PATCH 06/12] X.509: Use verify_signature() if we have a struct key * to use " David Howells
2016-03-04 15:01 ` [RFC PATCH 07/12] X.509: Move the trust validation code out to its own file " David Howells
2016-03-04 15:01 ` [RFC PATCH 08/12] KEYS: Make the system trusted keyring depend on the asymmetric key type " David Howells
2016-03-04 15:01 ` [RFC PATCH 09/12] KEYS: Move the point of trust determination to __key_link() " David Howells
2016-03-04 15:01 ` [RFC PATCH 10/12] KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED " David Howells
2016-03-04 15:01 ` [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically " David Howells
2016-03-08  2:05   ` Mimi Zohar
2016-03-08 13:13     ` David Howells
2016-03-08 14:06       ` Petko Manolov
2016-03-08 14:31       ` Mimi Zohar
2016-03-08 14:43         ` David Howells
2016-03-08 15:09           ` Mimi Zohar
2016-03-08 15:32             ` David Howells
2016-03-08 16:15               ` Mimi Zohar
2016-03-04 15:01 ` [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok " David Howells
2016-03-08  2:26   ` Mimi Zohar [this message]
2016-03-08 13:08     ` David Howells
2016-03-08 14:12       ` Mimi Zohar
2016-03-08 14:14       ` Petko Manolov
2016-03-08 14:38         ` Mimi Zohar
2016-03-08 14:44         ` David Howells
2016-03-08 15:48           ` Petko Manolov
2016-03-08 16:07         ` David Howells
2016-03-08 16:37           ` Petko Manolov
2016-03-08 22:05             ` 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=1457403993.5321.33.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.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 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.