mbox series

[v5,0/6] Add CA enforcement keyring restrictions

Message ID 20230302164652.83571-1-eric.snowberg@oracle.com
Headers
Series Add CA enforcement keyring restrictions |

Message

Eric Snowberg March 2, 2023, 4:46 p.m. UTC 
  Prior to the introduction of the machine keyring, most distros simply 
allowed all keys contained within the platform keyring to be used
for both kernel and module verification.  This was done by an out of
tree patch.  Some distros took it even further and loaded all these keys
into the secondary trusted keyring.  This also allowed the system owner 
to add their own key for IMA usage.

Each distro contains similar documentation on how to sign kernel modules
and enroll the key into the MOK.  The process is fairly straightforward.
With the introduction of the machine keyring, the process remains
basically the same, without the need for any out of tree patches.

The machine keyring allowed distros to eliminate the out of tree patches
for kernel module signing.  However, it falls short in allowing the end 
user to add their own keys for IMA. Currently, the machine keyring can not 
be used as another trust anchor for adding keys to the ima keyring, since 
CA enforcement does not currently exist.  This would expand the current 
integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY 
Kconfig states that keys may be added to the ima keyrings if the key is 
validly signed by a CA cert in the system built-in or secondary trusted 
keyring.  Currently, there is not code that enforces the contents of a
CA cert.

This series introduces a way to do CA enforcement with the machine
keyring.  It introduces three different ways to configure the machine
keyring.  New Kconfig options are added to control the types of keys
that may be added to it.  The default option allows all MOK keys into the
machine keyring.  When CONFIG_INTEGRITY_CA_MACHINE_KEYRING is selected,
the X.509 CA bit must be true and the key usage must contain keyCertSign; 
any other usage field may also be set.  When
CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is also selected, the X.509 CA
bit must be true and the key usage must contain keyCertSign. With this
option digitialSignature usage may not be set.  If a key doesn't pass 
the CA restriction check, instead of going into the machine keyring, it 
is added to the platform keyring.  With the ability to configure the
machine keyring with CA restrictions, code that prevented the machine
keyring from being enabled with
IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY has been removed.

Changelog:
v5:
- Removed the Kconfig _MIN Kconfig option and split it into different
  entries.
- Added requested commit message changes

v4:
- Removed all code that validated the certificate chain back to the root
  CA. Now the only restriction is what is initially placed in the
  machine keyring.
- Check and store if the X.509 usage contains digitalSignature
- New Kconfig menu item with none, min and max CA restriction on the 
  machine keyring

v3:
- Allow Intermediate CA certs to be enrolled through the MOK. The
  Intermediate CA cert must contain keyCertSign key usage and have the 
  CA bit set to true. This was done by removing the self signed
  requirement.

Eric Snowberg (6):
  KEYS: Create static version of public_key_verify_signature
  KEYS: Add missing function documentation
  KEYS: X.509: Parse Basic Constraints for CA
  KEYS: X.509: Parse Key Usage
  KEYS: CA link restriction
  integrity: machine keyring CA configuration

 certs/system_keyring.c                    | 14 +++++--
 crypto/asymmetric_keys/restrict.c         | 40 ++++++++++++++++++
 crypto/asymmetric_keys/x509_cert_parser.c | 50 +++++++++++++++++++++++
 include/crypto/public_key.h               | 28 +++++++++++++
 security/integrity/Kconfig                | 23 ++++++++++-
 security/integrity/digsig.c               |  8 +++-
 6 files changed, 157 insertions(+), 6 deletions(-)


base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c

Comments

Jarkko Sakkinen March 11, 2023, 10:09 p.m. UTC | #1 
On Thu, Mar 02, 2023 at 11:46:50AM -0500, Eric Snowberg wrote:
> Parse the X.509 Key Usage.  The key usage extension defines the purpose of
> the key contained in the certificate.
> 
>    id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
> 
>       KeyUsage ::= BIT STRING {
>            digitalSignature        (0),
>            contentCommitment       (1),
>            keyEncipherment         (2),
>            dataEncipherment        (3),
>            keyAgreement            (4),
>            keyCertSign             (5),
>            cRLSign                 (6),
>            encipherOnly            (7),
>            decipherOnly            (8) }
> 
> If the keyCertSign or digitalSignature is set, store it in the
> public_key structure. Having the purpose of the key being stored
> during parsing, allows enforcement on the usage field in the future.
> This will be used in a follow on patch that requires knowing the
> certificate key usage type.
> 
> Link: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
>  crypto/asymmetric_keys/x509_cert_parser.c | 28 +++++++++++++++++++++++
>  include/crypto/public_key.h               |  2 ++
>  2 files changed, 30 insertions(+)
> 
> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
> index 77547d4bd94d..0a7049b470c1 100644
> --- a/crypto/asymmetric_keys/x509_cert_parser.c
> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> @@ -579,6 +579,34 @@ int x509_process_extension(void *context, size_t hdrlen,
>  		return 0;
>  	}
>  
> +	if (ctx->last_oid == OID_keyUsage) {
> +		/*
> +		 * Get hold of the keyUsage bit string
> +		 * v[1] is the encoding size
> +		 *       (Expect either 0x02 or 0x03, making it 1 or 2 bytes)
> +		 * v[2] is the number of unused bits in the bit string
> +		 *       (If >= 3 keyCertSign is missing when v[1] = 0x02)
> +		 * v[3] and possibly v[4] contain the bit string
> +		 *
> +		 * From RFC 5280 4.2.1.3:
> +		 *   0x04 is where keyCertSign lands in this bit string
> +		 *   0x80 is where digitalSignature lands in this bit string
> +		 */
> +		if (v[0] != ASN1_BTS)
> +			return -EBADMSG;
> +		if (vlen < 4)
> +			return -EBADMSG;
> +		if (v[2] >= 8)
> +			return -EBADMSG;
> +		if (v[3] & 0x80)
> +			ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_DIGITALSIG;
> +		if (v[1] == 0x02 && v[2] <= 2 && (v[3] & 0x04))
> +			ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_KEYCERTSIGN;
> +		else if (vlen > 4 && v[1] == 0x03 && (v[3] & 0x04))
> +			ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_KEYCERTSIGN;
> +		return 0;
> +	}
> +
>  	if (ctx->last_oid == OID_authorityKeyIdentifier) {
>  		/* Get hold of the CA key fingerprint */
>  		ctx->raw_akid = v;
> diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
> index c401762850f2..03c3fb990d59 100644
> --- a/include/crypto/public_key.h
> +++ b/include/crypto/public_key.h
> @@ -30,6 +30,8 @@ struct public_key {
>  	const char *pkey_algo;
>  	unsigned long key_eflags;	/* key extension flags */
>  #define KEY_EFLAG_CA		0	/* set if the CA basic constraints is set */
> +#define KEY_EFLAG_DIGITALSIG	1	/* set if the digitalSignature usage is set */
> +#define KEY_EFLAG_KEYCERTSIGN	2	/* set if the keyCertSign usage is set */
>  };
>  
>  extern void public_key_free(struct public_key *key);
> -- 
> 2.27.0
> 

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

BR, Jarkko