I assume this is intended for 4.6 or later, correct?
Petko
On 16-01-19 11:30:26, David Howells wrote:
>
> Here's a set of patches that changes how certificates/keys are determined
> to be trusted. That's currently a two-step process:
>
> (1) Up until recently, when an X.509 certificate was parsed - no matter
> the source - it was judged against the keys in .system_keyring,
> assuming those keys to be trusted if they have KEY_FLAG_TRUSTED set
> upon them.
>
> This has just been changed such that any key in the .ima_mok keyring
> may also be used to judge the trustwortiness of a new certificate,
> whether or not the .ima_mok keyring is meant to be consulted for
> whatever process is being undertaken.
>
> If a certificate is determined to be trustworthy, KEY_FLAG_TRUSTED
> will be set upon a key it is loaded into (if it is loaded into one),
> no matter what the key is going to be loaded for.
>
> (2) If an X.509 certificate is loaded into a key, then that key - if
> KEY_FLAG_TRUSTED gets set upon it - can be linked into any keyring
> with KEY_FLAG_TRUSTED_ONLY set upon it. This was meant to be the
> system keyring only, but has been extended to various IMA keyrings.
>
> A user can at will link any key marked KEY_FLAG_TRUSTED into any
> keyring marked KEY_FLAG_TRUSTED_ONLY if the relevant permissions masks
> permit it.
>
> These patches change that:
>
> (1) Trust becomes a matter of consulting the ring of trusted keys supplied
> when the trust is evaluated only.
>
> (2) Asymmetric keys retain the source certificate signature information
> for future evaluation rather than discarding it.
>
> (3) Every keyring can be supplied with its own manager function to
> restrict what may be added to that keyring. This is called whenever a
> key is to be linked into the keyring to guard against a key being
> created in one keyring and then linked across.
>
> This function is supplied with the keyring and the key type and
> payload[*] of the key being linked in for use in its evaluation. It
> is permitted to use other data also, such as the contents of other
> keyrings such as the system keyrings.
>
> [*] The type and payload are supplied instead of a key because as an
> optimisation this function may be called whilst creating a key and
> so may reject the proposed key between preparse and allocation.
>
> (4) A default manager function is provided that permits keys to be
> restricted to only asymmetric keys that are vouched for by the
> contents of the system keyring.
>
> (5) A key allocation flag, KEY_ALLOC_BYPASS_RESTRICTION, is made available
> so that the kernel can initialise keyrings with keys that form the
> root of the trust relationship.
>
> (6) KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed, along with
> key_preparsed_payload::trusted.
>
> This change also makes it possible for userspace to create a private set of
> trusted keys and then to seal it by setting a manager function where the
> private set is wholly independent of the kernel's trust relationships.
>
> Further changes in the set involve extracting certain IMA special keyrings
> and making them generally global:
>
> (*) .system_keyring is renamed to .builtin_trusted_keys and remains read
> only. It carries only keys built in to the kernel. It may be where
> UEFI keys should be loaded - though that could better be the new
> secondary keyring (see below).
>
> (*) An optional system blacklist keyring is created to replace the IMA
> keyring.
>
> (*) A 'blacklist' key type is created that may contain a hex string in
> its description (it carries no payload). When an X.509
> certificate is parsed, the system blacklist is searched for a
> blacklist key that matches the TBS hash of the X.509 certificate
> and if one is found, the certificate is considered blacklisted.
>
> (*) A list of blacklisted hashes can be added to the system blacklist
> keyring at compile time. In the future it should also be possible
> to load this up from such as the UEFI blacklist.
>
> (*) Keys can be added to the blacklist keyring by root if the keys are
> signed by a key in the builtin system keyring. These can then be
> searched for by asymmetric key ID. This allows the functionality
> of the IMA blacklist keyring to be replicated.
>
> It might be worth making an asymmetric key subtype that carries no
> data to be used here as the cryptographic material is then just
> dead weight since the IDs are what matter.
>
> (*) An optional secondary system keyring (called .secondary_trusted_keys)
> is added to replace the IMA MOK keyring.
>
> (*) Keys can be added to the secondary keyring by root if the keys can
> be vouched for by either ring of system keys.
>
> (*) Module signing and kexec only use .builtin_trusted_keys and do not use
> the new secondary keyring, but they do consult the system blacklist.
>
> (*) If the kernel sees a PKCS#7 message with more than one signature, at
> least one of which is blacklisted, it will permit the message if at
> least one of the non-blacklisted signature chains is vouched for. If
> none are, then EKEYREJECTED will be given. This error takes priority
> over giving ENOPKG for unsupported encryption.
>
> The patches can be found here also:
>
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-trust
>
> David
> ---
> David Howells (20):
> KEYS: Add an alloc flag to convey the builtinness of a key
> KEYS: Add a system blacklist keyring
> X.509: Allow X.509 certs to be blacklisted
> X.509: Don't treat self-signed keys specially
> KEYS: Generalise system_verify_data() to provide access to internal
> content
> PKCS#7: Make trust determination dependent on contents of trust keyring
> KEYS: Add a facility to restrict new links into a keyring
> KEYS: Allow authentication data to be stored in an asymmetric key
> KEYS: Add identifier pointers to public_key_signature struct
> X.509: Retain the key verification data
> X.509: Extract signature digest and make self-signed cert checks earlier
> PKCS#7: Make the signature a pointer rather than embedding it
> X.509: Move the trust validation code out to its own file
> KEYS: Generalise x509_request_asymmetric_key()
> KEYS: Move the point of trust determination to __key_link()
> KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED
> PKCS#7: Handle blacklisted certificates
> IMA: Use the system blacklist keyring
> certs: Add a secondary system keyring that can be added to dynamically
> IMA: Replace the .ima_mok keyring with the secondary system keyring
>
>
> Documentation/security/keys.txt | 14 +
> arch/x86/kernel/kexec-bzimage64.c | 18 --
> certs/Kconfig | 26 ++
> certs/Makefile | 6 +
> certs/blacklist.c | 184 +++++++++++++++++
> certs/blacklist.h | 3
> certs/blacklist_hashes.c | 6 +
> certs/blacklist_nohashes.c | 5
> certs/system_keyring.c | 141 ++++++++++---
> crypto/asymmetric_keys/Kconfig | 1
> crypto/asymmetric_keys/Makefile | 2
> crypto/asymmetric_keys/asymmetric_keys.h | 2
> crypto/asymmetric_keys/asymmetric_type.c | 7 -
> crypto/asymmetric_keys/mscode_parser.c | 21 +-
> crypto/asymmetric_keys/pkcs7_key_type.c | 66 +++---
> crypto/asymmetric_keys/pkcs7_parser.c | 59 +++--
> crypto/asymmetric_keys/pkcs7_parser.h | 12 -
> crypto/asymmetric_keys/pkcs7_trust.c | 44 ++--
> crypto/asymmetric_keys/pkcs7_verify.c | 141 ++++++-------
> crypto/asymmetric_keys/public_key.c | 24 ++
> crypto/asymmetric_keys/public_key.h | 6 +
> crypto/asymmetric_keys/public_key_trust.c | 209 +++++++++++++++++++
> crypto/asymmetric_keys/verify_pefile.c | 40 +---
> crypto/asymmetric_keys/verify_pefile.h | 5
> crypto/asymmetric_keys/x509_cert_parser.c | 51 +++--
> crypto/asymmetric_keys/x509_parser.h | 13 +
> crypto/asymmetric_keys/x509_public_key.c | 318
> +++++++++--------------------
> fs/cifs/cifsacl.c | 2
> fs/nfs/nfs4idmap.c | 2
> include/crypto/pkcs7.h | 6 -
> include/crypto/public_key.h | 35 +--
> include/keys/asymmetric-subtype.h | 2
> include/keys/asymmetric-type.h | 8 -
> include/keys/system_keyring.h | 52 ++---
> include/linux/key-type.h | 1
> include/linux/key.h | 39 +++-
> include/linux/verification.h | 49 ++++
> include/linux/verify_pefile.h | 22 --
> kernel/module_signing.c | 7 -
> net/dns_resolver/dns_key.c | 2
> net/rxrpc/ar-key.c | 4
> security/integrity/digsig.c | 10 +
> security/integrity/digsig_asymmetric.c | 18 +-
> security/integrity/ima/Kconfig | 18 --
> security/integrity/ima/Makefile | 1
> security/integrity/ima/ima_mok.c | 55 -----
> security/keys/key.c | 44 +++-
> security/keys/keyring.c | 26 ++
> security/keys/persistent.c | 4
> security/keys/process_keys.c | 16 +
> security/keys/request_key.c | 4
> security/keys/request_key_auth.c | 2
> 52 files changed, 1131 insertions(+), 722 deletions(-)
> create mode 100644 certs/blacklist.c
> create mode 100644 certs/blacklist.h
> create mode 100644 certs/blacklist_hashes.c
> create mode 100644 certs/blacklist_nohashes.c
> create mode 100644 crypto/asymmetric_keys/public_key_trust.c
> create mode 100644 include/linux/verification.h
> delete mode 100644 include/linux/verify_pefile.h
> delete mode 100644 security/integrity/ima/ima_mok.c
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
