All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Snowberg <eric.snowberg@oracle.com>
To: jarkko@kernel.org, zohar@linux.ibm.com, dhowells@redhat.com,
	dwmw2@infradead.org
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
	dmitry.kasatkin@gmail.com, paul@paul-moore.com,
	jmorris@namei.org, serge@hallyn.com, pvorel@suse.cz,
	eric.snowberg@oracle.com, kanth.ghatraju@oracle.com,
	konrad.wilk@oracle.com, erpalmer@linux.vnet.ibm.com,
	coxu@redhat.com, jlee@suse.com, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: [PATCH v6 6/6] integrity: machine keyring CA configuration
Date: Wed, 22 Mar 2023 12:16:34 -0400	[thread overview]
Message-ID: <20230322161634.2233838-7-eric.snowberg@oracle.com> (raw)
In-Reply-To: <20230322161634.2233838-1-eric.snowberg@oracle.com>

Add machine keyring CA restriction options to control the type of
keys that may be added to it. The motivation is separation of
certificate signing from code signing keys. Subsquent work will
limit certificates being loaded into the IMA keyring to code
signing keys used for signature verification.

When no restrictions are selected, all Machine Owner Keys (MOK) are added
to the machine keyring.  When CONFIG_INTEGRITY_CA_MACHINE_KEYRING is
selected, the CA bit must be true.  Also the key usage must contain
keyCertSign, any other usage field may be set as well.

When CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is selected, the CA bit must
be true. Also the key usage must contain keyCertSign and the
digitialSignature usage may not be set.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
---
 crypto/asymmetric_keys/restrict.c |  3 +++
 security/integrity/Kconfig        | 23 ++++++++++++++++++++++-
 security/integrity/digsig.c       |  8 ++++++--
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/crypto/asymmetric_keys/restrict.c b/crypto/asymmetric_keys/restrict.c
index dd9ced32c8a1..d6cd1dc2bec8 100644
--- a/crypto/asymmetric_keys/restrict.c
+++ b/crypto/asymmetric_keys/restrict.c
@@ -144,6 +144,9 @@ int restrict_link_by_ca(struct key *dest_keyring,
 	if (!test_bit(KEY_EFLAG_KEYCERTSIGN, &pkey->key_eflags))
 		return -ENOKEY;
 
+	if (!IS_ENABLED(CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX))
+		return 0;
+
 	if (test_bit(KEY_EFLAG_DIGITALSIG, &pkey->key_eflags))
 		return -ENOKEY;
 
diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 599429f99f99..ec6e0d789da1 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -68,13 +68,34 @@ config INTEGRITY_MACHINE_KEYRING
 	depends on INTEGRITY_ASYMMETRIC_KEYS
 	depends on SYSTEM_BLACKLIST_KEYRING
 	depends on LOAD_UEFI_KEYS
-	depends on !IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
 	help
 	 If set, provide a keyring to which Machine Owner Keys (MOK) may
 	 be added. This keyring shall contain just MOK keys.  Unlike keys
 	 in the platform keyring, keys contained in the .machine keyring will
 	 be trusted within the kernel.
 
+config INTEGRITY_CA_MACHINE_KEYRING
+	bool "Enforce Machine Keyring CA Restrictions"
+	depends on INTEGRITY_MACHINE_KEYRING
+	default n
+	help
+	  The .machine keyring can be configured to enforce CA restriction
+	  on any key added to it.  By default no restrictions are in place
+	  and all Machine Owner Keys (MOK) are added to the machine keyring.
+	  If enabled only CA keys are added to the machine keyring, all
+	  other MOK keys load into the platform keyring.
+
+config INTEGRITY_CA_MACHINE_KEYRING_MAX
+	bool "Only CA keys without DigitialSignature usage set"
+	depends on INTEGRITY_CA_MACHINE_KEYRING
+	default n
+	help
+	  When selected, only load CA keys are loaded into the machine
+	  keyring that contain the CA bit set along with the keyCertSign
+	  Usage field.  Keys containing the digitialSignature Usage field
+	  will not be loaded. The remaining MOK keys are loaded into the
+	  .platform keyring.
+
 config LOAD_UEFI_KEYS
        depends on INTEGRITY_PLATFORM_KEYRING
        depends on EFI
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index f2193c531f4a..6f31ffe23c48 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -132,7 +132,8 @@ int __init integrity_init_keyring(const unsigned int id)
 		| KEY_USR_READ | KEY_USR_SEARCH;
 
 	if (id == INTEGRITY_KEYRING_PLATFORM ||
-	    id == INTEGRITY_KEYRING_MACHINE) {
+	    (id == INTEGRITY_KEYRING_MACHINE &&
+	    !IS_ENABLED(CONFIG_INTEGRITY_CA_MACHINE_KEYRING))) {
 		restriction = NULL;
 		goto out;
 	}
@@ -144,7 +145,10 @@ int __init integrity_init_keyring(const unsigned int id)
 	if (!restriction)
 		return -ENOMEM;
 
-	restriction->check = restrict_link_to_ima;
+	if (id == INTEGRITY_KEYRING_MACHINE)
+		restriction->check = restrict_link_by_ca;
+	else
+		restriction->check = restrict_link_to_ima;
 
 	/*
 	 * MOK keys can only be added through a read-only runtime services
-- 
2.27.0


  parent reply	other threads:[~2023-03-22 16:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22 16:16 [PATCH v6 0/6] Add CA enforcement keyring restrictions Eric Snowberg
2023-03-22 16:16 ` [PATCH v6 1/6] KEYS: Create static version of public_key_verify_signature Eric Snowberg
2023-03-22 16:16 ` [PATCH v6 2/6] KEYS: Add missing function documentation Eric Snowberg
2023-03-22 16:16 ` [PATCH v6 3/6] KEYS: X.509: Parse Basic Constraints for CA Eric Snowberg
2023-03-22 16:16 ` [PATCH v6 4/6] KEYS: X.509: Parse Key Usage Eric Snowberg
2023-03-22 16:16 ` [PATCH v6 5/6] KEYS: CA link restriction Eric Snowberg
2023-03-22 16:16 ` Eric Snowberg [this message]
2023-03-29 22:02 ` [PATCH v6 0/6] Add CA enforcement keyring restrictions Jarkko Sakkinen

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=20230322161634.2233838-7-eric.snowberg@oracle.com \
    --to=eric.snowberg@oracle.com \
    --cc=coxu@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=erpalmer@linux.vnet.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=jlee@suse.com \
    --cc=jmorris@namei.org \
    --cc=kanth.ghatraju@oracle.com \
    --cc=keyrings@vger.kernel.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=pvorel@suse.cz \
    --cc=serge@hallyn.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.