2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-25 13:43:55 +08:00
linux-next/certs/system_keyring.c

342 lines
9.9 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/* System trusted keyring for trusted public keys
*
* Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
* Written by David Howells (dhowells@redhat.com)
*/
#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/cred.h>
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/uidgid.h>
#include <linux/verification.h>
#include <keys/asymmetric-type.h>
#include <keys/system_keyring.h>
#include <crypto/pkcs7.h>
#include "common.h"
static struct key *builtin_trusted_keys;
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
static struct key *secondary_trusted_keys;
#endif
#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
static struct key *machine_trusted_keys;
#endif
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
static struct key *platform_trusted_keys;
#endif
extern __initconst const u8 system_certificate_list[];
extern __initconst const unsigned long system_certificate_list_size;
extern __initconst const unsigned long module_cert_size;
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 23:14:26 +08:00
/**
* restrict_link_to_builtin_trusted - Restrict keyring addition by built in CA
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 23:14:26 +08:00
*
* Restrict the addition of keys into a keyring based on the key-to-be-added
* being vouched for by a key in the built in system keyring.
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 23:14:26 +08:00
*/
int restrict_link_by_builtin_trusted(struct key *dest_keyring,
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 23:14:26 +08:00
const struct key_type *type,
const union key_payload *payload,
struct key *restriction_key)
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 23:14:26 +08:00
{
return restrict_link_by_signature(dest_keyring, type, payload,
builtin_trusted_keys);
KEYS: Move the point of trust determination to __key_link() Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06 23:14:26 +08:00
}
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
/**
* restrict_link_by_builtin_and_secondary_trusted - Restrict keyring
* addition by both builtin and secondary keyrings
*
* Restrict the addition of keys into a keyring based on the key-to-be-added
* being vouched for by a key in either the built-in or the secondary system
* keyrings.
*/
int restrict_link_by_builtin_and_secondary_trusted(
struct key *dest_keyring,
const struct key_type *type,
const union key_payload *payload,
struct key *restrict_key)
{
/* If we have a secondary trusted keyring, then that contains a link
* through to the builtin keyring and the search will follow that link.
*/
if (type == &key_type_keyring &&
dest_keyring == secondary_trusted_keys &&
payload == &builtin_trusted_keys->payload)
/* Allow the builtin keyring to be added to the secondary */
return 0;
return restrict_link_by_signature(dest_keyring, type, payload,
secondary_trusted_keys);
}
/**
* Allocate a struct key_restriction for the "builtin and secondary trust"
* keyring. Only for use in system_trusted_keyring_init().
*/
static __init struct key_restriction *get_builtin_and_secondary_restriction(void)
{
struct key_restriction *restriction;
restriction = kzalloc(sizeof(struct key_restriction), GFP_KERNEL);
if (!restriction)
panic("Can't allocate secondary trusted keyring restriction\n");
if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING))
restriction->check = restrict_link_by_builtin_secondary_and_machine;
else
restriction->check = restrict_link_by_builtin_and_secondary_trusted;
return restriction;
}
#endif
#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
void __init set_machine_trusted_keys(struct key *keyring)
{
machine_trusted_keys = keyring;
if (key_link(secondary_trusted_keys, machine_trusted_keys) < 0)
panic("Can't link (machine) trusted keyrings\n");
}
/**
* restrict_link_by_builtin_secondary_and_machine - Restrict keyring addition.
* @dest_keyring: Keyring being linked to.
* @type: The type of key being added.
* @payload: The payload of the new key.
* @restrict_key: A ring of keys that can be used to vouch for the new cert.
*
* Restrict the addition of keys into a keyring based on the key-to-be-added
* being vouched for by a key in either the built-in, the secondary, or
* the machine keyrings.
*/
int restrict_link_by_builtin_secondary_and_machine(
struct key *dest_keyring,
const struct key_type *type,
const union key_payload *payload,
struct key *restrict_key)
{
if (machine_trusted_keys && type == &key_type_keyring &&
dest_keyring == secondary_trusted_keys &&
payload == &machine_trusted_keys->payload)
/* Allow the machine keyring to be added to the secondary */
return 0;
return restrict_link_by_builtin_and_secondary_trusted(dest_keyring, type,
payload, restrict_key);
}
#endif
/*
* Create the trusted keyrings
*/
static __init int system_trusted_keyring_init(void)
{
pr_notice("Initialise system trusted keyrings\n");
builtin_trusted_keys =
keyring_alloc(".builtin_trusted_keys",
GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
((KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH),
KEY_ALLOC_NOT_IN_QUOTA,
NULL, NULL);
if (IS_ERR(builtin_trusted_keys))
panic("Can't allocate builtin trusted keyring\n");
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
secondary_trusted_keys =
keyring_alloc(".secondary_trusted_keys",
GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
((KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH |
KEY_USR_WRITE),
KEY_ALLOC_NOT_IN_QUOTA,
get_builtin_and_secondary_restriction(),
NULL);
if (IS_ERR(secondary_trusted_keys))
panic("Can't allocate secondary trusted keyring\n");
if (key_link(secondary_trusted_keys, builtin_trusted_keys) < 0)
panic("Can't link trusted keyrings\n");
#endif
return 0;
}
/*
* Must be initialised before we try and load the keys into the keyring.
*/
device_initcall(system_trusted_keyring_init);
__init int load_module_cert(struct key *keyring)
{
if (!IS_ENABLED(CONFIG_IMA_APPRAISE_MODSIG))
return 0;
pr_notice("Loading compiled-in module X.509 certificates\n");
integrity-v5.13 -----BEGIN PGP SIGNATURE----- iQJIBAABCAAyFiEEjSMCCC7+cjo3nszSa3kkZrA+cVoFAmCIuMgUHHpvaGFyQGxp bnV4LmlibS5jb20ACgkQa3kkZrA+cVqCew//SHwZ3LuqZUyqX1lCeW0eUsJQmf9P Rc++pK5+cigaYwg/LpLXBtIthOO91KJ+p4UrXIttlz6wRWqH5Enm/nQk3ngIIrWJ g4HsU4LoXeE5V1QZgDdUWM+ViaNvZuzT8enaUt4VvelHTRMoAgeTu7/amjx01t9L R8Qhmg2tBI5ehRgocNfEApNfaDyOcJhR14wAnGFhQH1pH2o0e+O+L5E6ke3Z2N0D oa9LBkA2wZFlTXkYHAYBdZjPW0BXX55brIusLHhrvFC16Ad9IVwcxRvRwYy4v2IK p8kO7EwGO4IkqsuL6FApgbW8/dTZXo3pD8YmplXhQdvAd9L/LshYhDePX7UsEp+O CL3rFvNFzZKC5qTx0UXLqjcktosOLTTFkAzRMg5taTljbTWBp9ziI8X0nTgoThLH fTs41Ol5v5veiq8JbZ1VixCoDJVOWtED/FuSZD41OyXJb7yGNpTnmvP6QJNIa1Yo vWsxSWmEX62xT85CzYLBR1Ow5+9t9+IjoCRt0pu0SRSps4gYcg1BjS+gIFnuCtB/ B9Ysh+rHo9ne9iojFd9TrEYQSAXebVEYSOjqPWV3E7gd0EXuF+JY0akj8JBduHt3 mfogxVtJdaHDjHtpHoHhBTpHG8l/E2n/47eFDmCiTsBGdL54R4jJSkOu8QmWBgzz HVNX+f86SJ2haUw= =gkFF -----END PGP SIGNATURE----- Merge tag 'integrity-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull IMA updates from Mimi Zohar: "In addition to loading the kernel module signing key onto the builtin keyring, load it onto the IMA keyring as well. Also six trivial changes and bug fixes" * tag 'integrity-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: ensure IMA_APPRAISE_MODSIG has necessary dependencies ima: Fix fall-through warnings for Clang integrity: Add declarations to init_once void arguments. ima: Fix function name error in comment. ima: enable loading of build time generated key on .ima keyring ima: enable signing of modules with build time generated key keys: cleanup build time module signing keys ima: Fix the error code for restoring the PCR value ima: without an IMA policy loaded, return quickly
2021-05-02 06:32:18 +08:00
return load_certificate_list(system_certificate_list, module_cert_size, keyring);
}
/*
* Load the compiled-in list of X.509 certificates.
*/
static __init int load_system_certificate_list(void)
{
integrity-v5.13 -----BEGIN PGP SIGNATURE----- iQJIBAABCAAyFiEEjSMCCC7+cjo3nszSa3kkZrA+cVoFAmCIuMgUHHpvaGFyQGxp bnV4LmlibS5jb20ACgkQa3kkZrA+cVqCew//SHwZ3LuqZUyqX1lCeW0eUsJQmf9P Rc++pK5+cigaYwg/LpLXBtIthOO91KJ+p4UrXIttlz6wRWqH5Enm/nQk3ngIIrWJ g4HsU4LoXeE5V1QZgDdUWM+ViaNvZuzT8enaUt4VvelHTRMoAgeTu7/amjx01t9L R8Qhmg2tBI5ehRgocNfEApNfaDyOcJhR14wAnGFhQH1pH2o0e+O+L5E6ke3Z2N0D oa9LBkA2wZFlTXkYHAYBdZjPW0BXX55brIusLHhrvFC16Ad9IVwcxRvRwYy4v2IK p8kO7EwGO4IkqsuL6FApgbW8/dTZXo3pD8YmplXhQdvAd9L/LshYhDePX7UsEp+O CL3rFvNFzZKC5qTx0UXLqjcktosOLTTFkAzRMg5taTljbTWBp9ziI8X0nTgoThLH fTs41Ol5v5veiq8JbZ1VixCoDJVOWtED/FuSZD41OyXJb7yGNpTnmvP6QJNIa1Yo vWsxSWmEX62xT85CzYLBR1Ow5+9t9+IjoCRt0pu0SRSps4gYcg1BjS+gIFnuCtB/ B9Ysh+rHo9ne9iojFd9TrEYQSAXebVEYSOjqPWV3E7gd0EXuF+JY0akj8JBduHt3 mfogxVtJdaHDjHtpHoHhBTpHG8l/E2n/47eFDmCiTsBGdL54R4jJSkOu8QmWBgzz HVNX+f86SJ2haUw= =gkFF -----END PGP SIGNATURE----- Merge tag 'integrity-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull IMA updates from Mimi Zohar: "In addition to loading the kernel module signing key onto the builtin keyring, load it onto the IMA keyring as well. Also six trivial changes and bug fixes" * tag 'integrity-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: ensure IMA_APPRAISE_MODSIG has necessary dependencies ima: Fix fall-through warnings for Clang integrity: Add declarations to init_once void arguments. ima: Fix function name error in comment. ima: enable loading of build time generated key on .ima keyring ima: enable signing of modules with build time generated key keys: cleanup build time module signing keys ima: Fix the error code for restoring the PCR value ima: without an IMA policy loaded, return quickly
2021-05-02 06:32:18 +08:00
const u8 *p;
unsigned long size;
pr_notice("Loading compiled-in X.509 certificates\n");
#ifdef CONFIG_MODULE_SIG
p = system_certificate_list;
size = system_certificate_list_size;
#else
p = system_certificate_list + module_cert_size;
size = system_certificate_list_size - module_cert_size;
#endif
integrity-v5.13 -----BEGIN PGP SIGNATURE----- iQJIBAABCAAyFiEEjSMCCC7+cjo3nszSa3kkZrA+cVoFAmCIuMgUHHpvaGFyQGxp bnV4LmlibS5jb20ACgkQa3kkZrA+cVqCew//SHwZ3LuqZUyqX1lCeW0eUsJQmf9P Rc++pK5+cigaYwg/LpLXBtIthOO91KJ+p4UrXIttlz6wRWqH5Enm/nQk3ngIIrWJ g4HsU4LoXeE5V1QZgDdUWM+ViaNvZuzT8enaUt4VvelHTRMoAgeTu7/amjx01t9L R8Qhmg2tBI5ehRgocNfEApNfaDyOcJhR14wAnGFhQH1pH2o0e+O+L5E6ke3Z2N0D oa9LBkA2wZFlTXkYHAYBdZjPW0BXX55brIusLHhrvFC16Ad9IVwcxRvRwYy4v2IK p8kO7EwGO4IkqsuL6FApgbW8/dTZXo3pD8YmplXhQdvAd9L/LshYhDePX7UsEp+O CL3rFvNFzZKC5qTx0UXLqjcktosOLTTFkAzRMg5taTljbTWBp9ziI8X0nTgoThLH fTs41Ol5v5veiq8JbZ1VixCoDJVOWtED/FuSZD41OyXJb7yGNpTnmvP6QJNIa1Yo vWsxSWmEX62xT85CzYLBR1Ow5+9t9+IjoCRt0pu0SRSps4gYcg1BjS+gIFnuCtB/ B9Ysh+rHo9ne9iojFd9TrEYQSAXebVEYSOjqPWV3E7gd0EXuF+JY0akj8JBduHt3 mfogxVtJdaHDjHtpHoHhBTpHG8l/E2n/47eFDmCiTsBGdL54R4jJSkOu8QmWBgzz HVNX+f86SJ2haUw= =gkFF -----END PGP SIGNATURE----- Merge tag 'integrity-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull IMA updates from Mimi Zohar: "In addition to loading the kernel module signing key onto the builtin keyring, load it onto the IMA keyring as well. Also six trivial changes and bug fixes" * tag 'integrity-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: ensure IMA_APPRAISE_MODSIG has necessary dependencies ima: Fix fall-through warnings for Clang integrity: Add declarations to init_once void arguments. ima: Fix function name error in comment. ima: enable loading of build time generated key on .ima keyring ima: enable signing of modules with build time generated key keys: cleanup build time module signing keys ima: Fix the error code for restoring the PCR value ima: without an IMA policy loaded, return quickly
2021-05-02 06:32:18 +08:00
return load_certificate_list(p, size, builtin_trusted_keys);
}
late_initcall(load_system_certificate_list);
#ifdef CONFIG_SYSTEM_DATA_VERIFICATION
/**
* verify_pkcs7_message_sig - Verify a PKCS#7-based signature on system data.
* @data: The data to be verified (NULL if expecting internal data).
* @len: Size of @data.
* @pkcs7: The PKCS#7 message that is the signature.
* @trusted_keys: Trusted keys to use (NULL for builtin trusted keys only,
* (void *)1UL for all trusted keys).
PKCS#7: Appropriately restrict authenticated attributes and content type A PKCS#7 or CMS message can have per-signature authenticated attributes that are digested as a lump and signed by the authorising key for that signature. If such attributes exist, the content digest isn't itself signed, but rather it is included in a special authattr which then contributes to the signature. Further, we already require the master message content type to be pkcs7_signedData - but there's also a separate content type for the data itself within the SignedData object and this must be repeated inside the authattrs for each signer [RFC2315 9.2, RFC5652 11.1]. We should really validate the authattrs if they exist or forbid them entirely as appropriate. To this end: (1) Alter the PKCS#7 parser to reject any message that has more than one signature where at least one signature has authattrs and at least one that does not. (2) Validate authattrs if they are present and strongly restrict them. Only the following authattrs are permitted and all others are rejected: (a) contentType. This is checked to be an OID that matches the content type in the SignedData object. (b) messageDigest. This must match the crypto digest of the data. (c) signingTime. If present, we check that this is a valid, parseable UTCTime or GeneralTime and that the date it encodes fits within the validity window of the matching X.509 cert. (d) S/MIME capabilities. We don't check the contents. (e) Authenticode SP Opus Info. We don't check the contents. (f) Authenticode Statement Type. We don't check the contents. The message is rejected if (a) or (b) are missing. If the message is an Authenticode type, the message is rejected if (e) is missing; if not Authenticode, the message is rejected if (d) - (f) are present. The S/MIME capabilities authattr (d) unfortunately has to be allowed to support kernels already signed by the pesign program. This only affects kexec. sign-file suppresses them (CMS_NOSMIMECAP). The message is also rejected if an authattr is given more than once or if it contains more than one element in its set of values. (3) Add a parameter to pkcs7_verify() to select one of the following restrictions and pass in the appropriate option from the callers: (*) VERIFYING_MODULE_SIGNATURE This requires that the SignedData content type be pkcs7-data and forbids authattrs. sign-file sets CMS_NOATTR. We could be more flexible and permit authattrs optionally, but only permit minimal content. (*) VERIFYING_FIRMWARE_SIGNATURE This requires that the SignedData content type be pkcs7-data and requires authattrs. In future, this will require an attribute holding the target firmware name in addition to the minimal set. (*) VERIFYING_UNSPECIFIED_SIGNATURE This requires that the SignedData content type be pkcs7-data but allows either no authattrs or only permits the minimal set. (*) VERIFYING_KEXEC_PE_SIGNATURE This only supports the Authenticode SPC_INDIRECT_DATA content type and requires at least an SpcSpOpusInfo authattr in addition to the minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and an S/MIME capabilities authattr because the pesign program doesn't remove these). (*) VERIFYING_KEY_SIGNATURE (*) VERIFYING_KEY_SELF_SIGNATURE These are invalid in this context but are included for later use when limiting the use of X.509 certs. (4) The pkcs7_test key type is given a module parameter to select between the above options for testing purposes. For example: echo 1 >/sys/module/pkcs7_test_key/parameters/usage keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7 will attempt to check the signature on stuff.pkcs7 as if it contains a firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE). Suggested-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 22:22:27 +08:00
* @usage: The use to which the key is being put.
* @view_content: Callback to gain access to content.
* @ctx: Context for callback.
*/
int verify_pkcs7_message_sig(const void *data, size_t len,
struct pkcs7_message *pkcs7,
struct key *trusted_keys,
enum key_being_used_for usage,
int (*view_content)(void *ctx,
const void *data, size_t len,
size_t asn1hdrlen),
void *ctx)
{
int ret;
/* The data should be detached - so we need to supply it. */
if (data && pkcs7_supply_detached_data(pkcs7, data, len) < 0) {
pr_err("PKCS#7 signature with non-detached data\n");
ret = -EBADMSG;
goto error;
}
PKCS#7: Appropriately restrict authenticated attributes and content type A PKCS#7 or CMS message can have per-signature authenticated attributes that are digested as a lump and signed by the authorising key for that signature. If such attributes exist, the content digest isn't itself signed, but rather it is included in a special authattr which then contributes to the signature. Further, we already require the master message content type to be pkcs7_signedData - but there's also a separate content type for the data itself within the SignedData object and this must be repeated inside the authattrs for each signer [RFC2315 9.2, RFC5652 11.1]. We should really validate the authattrs if they exist or forbid them entirely as appropriate. To this end: (1) Alter the PKCS#7 parser to reject any message that has more than one signature where at least one signature has authattrs and at least one that does not. (2) Validate authattrs if they are present and strongly restrict them. Only the following authattrs are permitted and all others are rejected: (a) contentType. This is checked to be an OID that matches the content type in the SignedData object. (b) messageDigest. This must match the crypto digest of the data. (c) signingTime. If present, we check that this is a valid, parseable UTCTime or GeneralTime and that the date it encodes fits within the validity window of the matching X.509 cert. (d) S/MIME capabilities. We don't check the contents. (e) Authenticode SP Opus Info. We don't check the contents. (f) Authenticode Statement Type. We don't check the contents. The message is rejected if (a) or (b) are missing. If the message is an Authenticode type, the message is rejected if (e) is missing; if not Authenticode, the message is rejected if (d) - (f) are present. The S/MIME capabilities authattr (d) unfortunately has to be allowed to support kernels already signed by the pesign program. This only affects kexec. sign-file suppresses them (CMS_NOSMIMECAP). The message is also rejected if an authattr is given more than once or if it contains more than one element in its set of values. (3) Add a parameter to pkcs7_verify() to select one of the following restrictions and pass in the appropriate option from the callers: (*) VERIFYING_MODULE_SIGNATURE This requires that the SignedData content type be pkcs7-data and forbids authattrs. sign-file sets CMS_NOATTR. We could be more flexible and permit authattrs optionally, but only permit minimal content. (*) VERIFYING_FIRMWARE_SIGNATURE This requires that the SignedData content type be pkcs7-data and requires authattrs. In future, this will require an attribute holding the target firmware name in addition to the minimal set. (*) VERIFYING_UNSPECIFIED_SIGNATURE This requires that the SignedData content type be pkcs7-data but allows either no authattrs or only permits the minimal set. (*) VERIFYING_KEXEC_PE_SIGNATURE This only supports the Authenticode SPC_INDIRECT_DATA content type and requires at least an SpcSpOpusInfo authattr in addition to the minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and an S/MIME capabilities authattr because the pesign program doesn't remove these). (*) VERIFYING_KEY_SIGNATURE (*) VERIFYING_KEY_SELF_SIGNATURE These are invalid in this context but are included for later use when limiting the use of X.509 certs. (4) The pkcs7_test key type is given a module parameter to select between the above options for testing purposes. For example: echo 1 >/sys/module/pkcs7_test_key/parameters/usage keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7 will attempt to check the signature on stuff.pkcs7 as if it contains a firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE). Suggested-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 22:22:27 +08:00
ret = pkcs7_verify(pkcs7, usage);
if (ret < 0)
goto error;
if (!trusted_keys) {
trusted_keys = builtin_trusted_keys;
} else if (trusted_keys == VERIFY_USE_SECONDARY_KEYRING) {
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
trusted_keys = secondary_trusted_keys;
#else
trusted_keys = builtin_trusted_keys;
#endif
} else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
trusted_keys = platform_trusted_keys;
#else
trusted_keys = NULL;
#endif
if (!trusted_keys) {
ret = -ENOKEY;
pr_devel("PKCS#7 platform keyring is not available\n");
goto error;
}
certs: Add EFI_CERT_X509_GUID support for dbx entries This fixes CVE-2020-26541. The Secure Boot Forbidden Signature Database, dbx, contains a list of now revoked signatures and keys previously approved to boot with UEFI Secure Boot enabled. The dbx is capable of containing any number of EFI_CERT_X509_SHA256_GUID, EFI_CERT_SHA256_GUID, and EFI_CERT_X509_GUID entries. Currently when EFI_CERT_X509_GUID are contained in the dbx, the entries are skipped. Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID is found, it is added as an asymmetrical key to the .blacklist keyring. Anytime the .platform keyring is used, the keys in the .blacklist keyring are referenced, if a matching key is found, the key will be rejected. [DH: Made the following changes: - Added to have a config option to enable the facility. This allows a Kconfig solution to make sure that pkcs7_validate_trust() is enabled.[1][2] - Moved the functions out from the middle of the blacklist functions. - Added kerneldoc comments.] Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> cc: Randy Dunlap <rdunlap@infradead.org> cc: Mickaël Salaün <mic@digikod.net> cc: Arnd Bergmann <arnd@kernel.org> cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/20200901165143.10295-1-eric.snowberg@oracle.com/ # rfc Link: https://lore.kernel.org/r/20200909172736.73003-1-eric.snowberg@oracle.com/ # v2 Link: https://lore.kernel.org/r/20200911182230.62266-1-eric.snowberg@oracle.com/ # v3 Link: https://lore.kernel.org/r/20200916004927.64276-1-eric.snowberg@oracle.com/ # v4 Link: https://lore.kernel.org/r/20210122181054.32635-2-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428672051.677100.11064981943343605138.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433310942.902181.4901864302675874242.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529605075.163428.14625520893961300757.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/bc2c24e3-ed68-2521-0bf4-a1f6be4a895d@infradead.org/ [1] Link: https://lore.kernel.org/r/20210225125638.1841436-1-arnd@kernel.org/ [2]
2021-01-23 02:10:51 +08:00
ret = is_key_on_revocation_list(pkcs7);
if (ret != -ENOKEY) {
pr_devel("PKCS#7 platform key is on revocation list\n");
goto error;
}
}
ret = pkcs7_validate_trust(pkcs7, trusted_keys);
if (ret < 0) {
if (ret == -ENOKEY)
pr_devel("PKCS#7 signature not signed with a trusted key\n");
goto error;
}
if (view_content) {
size_t asn1hdrlen;
ret = pkcs7_get_content_data(pkcs7, &data, &len, &asn1hdrlen);
if (ret < 0) {
if (ret == -ENODATA)
pr_devel("PKCS#7 message does not contain data\n");
goto error;
}
ret = view_content(ctx, data, len, asn1hdrlen);
}
error:
pr_devel("<==%s() = %d\n", __func__, ret);
return ret;
}
/**
* verify_pkcs7_signature - Verify a PKCS#7-based signature on system data.
* @data: The data to be verified (NULL if expecting internal data).
* @len: Size of @data.
* @raw_pkcs7: The PKCS#7 message that is the signature.
* @pkcs7_len: The size of @raw_pkcs7.
* @trusted_keys: Trusted keys to use (NULL for builtin trusted keys only,
* (void *)1UL for all trusted keys).
* @usage: The use to which the key is being put.
* @view_content: Callback to gain access to content.
* @ctx: Context for callback.
*/
int verify_pkcs7_signature(const void *data, size_t len,
const void *raw_pkcs7, size_t pkcs7_len,
struct key *trusted_keys,
enum key_being_used_for usage,
int (*view_content)(void *ctx,
const void *data, size_t len,
size_t asn1hdrlen),
void *ctx)
{
struct pkcs7_message *pkcs7;
int ret;
pkcs7 = pkcs7_parse_message(raw_pkcs7, pkcs7_len);
if (IS_ERR(pkcs7))
return PTR_ERR(pkcs7);
ret = verify_pkcs7_message_sig(data, len, pkcs7, trusted_keys, usage,
view_content, ctx);
pkcs7_free_message(pkcs7);
pr_devel("<==%s() = %d\n", __func__, ret);
return ret;
}
EXPORT_SYMBOL_GPL(verify_pkcs7_signature);
#endif /* CONFIG_SYSTEM_DATA_VERIFICATION */
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
void __init set_platform_trusted_keys(struct key *keyring)
{
platform_trusted_keys = keyring;
}
#endif