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
>
next prev parent 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 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).