linux-stable.git/include/keys/system_keyring.h, branch linux-5.4.y

certs: Add EFI_CERT_X509_GUID support for dbx entries

2021-06-30T12:47:55+00:00

[ Upstream commit 56c5812623f95313f6a46fbf0beee7fa17c68bbf ]

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 
Signed-off-by: David Howells 
Reviewed-by: Jarkko Sakkinen 
cc: Randy Dunlap 
cc: Mickaël Salaün 
cc: Arnd Bergmann 
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]
Signed-off-by: Sasha Levin

certs: Add wrapper function to check blacklisted binary hash

2021-06-30T12:47:55+00:00

[ Upstream commit 2434f7d2d488c3301ae81f1031e1c66c6f076fb7 ]

The -EKEYREJECTED error returned by existing is_hash_blacklisted() is
misleading when called for checking against blacklisted hash of a
binary.

This patch adds a wrapper function is_binary_blacklisted() to return
-EPERM error if binary is blacklisted.

Signed-off-by: Nayna Jain 
Reviewed-by: Mimi Zohar 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/1572492694-6520-7-git-send-email-zohar@linux.ibm.com
Signed-off-by: Sasha Levin

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 36

2019-05-24T15:27:11+00:00

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public licence as published by
  the free software foundation either version 2 of the licence or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 114 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Allison Randal 
Reviewed-by: Kate Stewart 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520170857.552531963@linutronix.de
Signed-off-by: Greg Kroah-Hartman

integrity, KEYS: add a reference to platform keyring

2019-02-04T22:29:19+00:00

commit 9dc92c45177a ("integrity: Define a trusted platform keyring")
introduced a .platform keyring for storing preboot keys, used for
verifying kernel image signatures. Currently only IMA-appraisal is able
to use the keyring to verify kernel images that have their signature
stored in xattr.

This patch exposes the .platform keyring, making it accessible for
verifying PE signed kernel images as well.

Suggested-by: Mimi Zohar 
Signed-off-by: Kairui Song 
Cc: David Howells 
[zohar@linux.ibm.com: fixed checkpatch errors, squashed with patch fix]
Signed-off-by: Mimi Zohar

KEYS: Split role of the keyring pointer for keyring restrict functions

2017-04-03T17:24:56+00:00

The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.

Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.

Signed-off-by: Mat Martineau

KEYS: Add a system blacklist keyring

2017-04-03T15:07:24+00:00

Add the following:

 (1) A new system keyring that is used to store information about
     blacklisted certificates and signatures.

 (2) A new key type (called 'blacklist') that is used to store a
     blacklisted hash in its description as a hex string.  The key accepts
     no payload.

 (3) The ability to configure a list of blacklisted hashes into the kernel
     at build time.  This is done by setting
     CONFIG_SYSTEM_BLACKLIST_HASH_LIST to the filename of a list of hashes
     that are in the form:

	"", "", ..., ""

     where each  is a hex string representation of the hash and must
     include all necessary leading zeros to pad the hash to the right size.

The above are enabled with CONFIG_SYSTEM_BLACKLIST_KEYRING.

Once the kernel is booted, the blacklist keyring can be listed:

	root@andromeda ~]# keyctl show %:.blacklist
	Keyring
	 723359729 ---lswrv      0     0  keyring: .blacklist
	 676257228 ---lswrv      0     0   \_ blacklist: 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46

The blacklist cannot currently be modified by userspace, but it will be
possible to load it, for example, from the UEFI blacklist database.

A later commit will make it possible to load blacklisted asymmetric keys in
here too.

Signed-off-by: David Howells

IMA: Use the the system trusted keyrings instead of .ima_mok

2016-04-11T21:49:15+00:00

Add a config option (IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY)
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.

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.

The .ima_mok keyring is then removed and the IMA blacklist keyring gets its
own config option (IMA_BLACKLIST_KEYRING).

Signed-off-by: David Howells 
Signed-off-by: Mimi Zohar

certs: Add a secondary system keyring that can be added to dynamically

2016-04-11T21:48:09+00:00

Add a secondary system keyring that can be added to by root whilst the
system is running - provided the key being added is vouched for by a key
built into the kernel or already added to the secondary keyring.

Rename .system_keyring to .builtin_trusted_keys to distinguish it more
obviously from the new keyring (called .secondary_trusted_keys).

The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING.

If the secondary keyring is enabled, a link is created from that to
.builtin_trusted_keys so that the the latter will automatically be searched
too if the secondary keyring is searched.

Signed-off-by: David Howells

KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED

2016-04-11T21:44:15+00:00

Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer
meaningful.  Also we can drop the trusted flag from the preparse structure.

Given this, we no longer need to pass the key flags through to
restrict_link().

Further, we can now get rid of keyring_restrict_trusted_only() also.

Signed-off-by: David Howells

KEYS: Move the point of trust determination to __key_link()

2016-04-11T21:43:43+00:00

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