[RFC PATCH 00/12] KEYS: Restrict additions to 'trusted' keyrings [ver #3]

From: David Howells
Date: Wed Mar 09 2016 - 06:18:28 EST



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,
if configured, may also be used to judge the trustworthiness 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.

(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.

A second manager function is provided that just rejects with EPERM.

(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 in future for userspace to create a private
set of trusted keys and then to have it sealed 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) or a separate UEFI keyring.

(*) 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.

(*) Config option SYSTEM_TRUSTED_KEYS now depends on ASYMMETRIC_KEY_TYPE as
that's the only type currently permitted on the system keyrings.

(*) A new config option, IMA_PERMIT_ADD_TO_IMA_KEYRINGS, is provided to allow
keys to be added to IMA keyrings - subject to the restriction that such
keys are validly signed by a key already in the system keyrings.

If IMA_PERMIT_ADD_TO_IMA_KEYRINGS is enabled, but secondary keyrings
aren't, additions to the IMA keyrings will be restricted to signatures
verifiable by keys in the builtin system keyring only.

The patches can be found here also:

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-trust

This patchset is based on top of

[RFC PATCH 0/7] KEYS: Adjust public key signature handling

which is on branch keys-sig in the GIT repo mentioned above.

David
---
David Howells (12):
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: Move x509_request_asymmetric_key() to asymmetric_type.c
KEYS: Generalise x509_request_asymmetric_key()
X.509: Use verify_signature() if we have a struct key * to use
X.509: Move the trust validation code out to its own file
KEYS: Make the system trusted keyring depend on the asymmetric key type
KEYS: Move the point of trust determination to __key_link()
KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED
certs: Add a secondary system keyring that can be added to dynamically
IMA: Use the the system trusted keyrings instead of .ima_mok


Documentation/security/keys.txt | 22 +++
arch/x86/kernel/kexec-bzimage64.c | 18 +--
certs/Kconfig | 9 +
certs/system_keyring.c | 139 ++++++++++++++++++----
crypto/asymmetric_keys/Kconfig | 6 -
crypto/asymmetric_keys/Makefile | 5 +
crypto/asymmetric_keys/asymmetric_keys.h | 2
crypto/asymmetric_keys/asymmetric_type.c | 89 ++++++++++++++
crypto/asymmetric_keys/mscode_parser.c | 21 +--
crypto/asymmetric_keys/pkcs7_key_type.c | 72 ++++-------
crypto/asymmetric_keys/pkcs7_parser.c | 21 ++-
crypto/asymmetric_keys/pkcs7_parser.h | 1
crypto/asymmetric_keys/pkcs7_trust.c | 35 ++---
crypto/asymmetric_keys/restrict.c | 108 +++++++++++++++++
crypto/asymmetric_keys/verify_pefile.c | 40 +-----
crypto/asymmetric_keys/verify_pefile.h | 5 -
crypto/asymmetric_keys/x509_parser.h | 1
crypto/asymmetric_keys/x509_public_key.c | 191 ------------------------------
fs/cifs/cifsacl.c | 2
fs/nfs/nfs4idmap.c | 2
include/crypto/pkcs7.h | 6 -
include/crypto/public_key.h | 27 +---
include/keys/asymmetric-type.h | 6 +
include/keys/system_keyring.h | 37 ++----
include/linux/key-type.h | 1
include/linux/key.h | 44 +++++--
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 | 18 ++-
security/integrity/ima/Kconfig | 62 ++++++++--
security/integrity/ima/ima_mok.c | 21 +--
security/keys/key.c | 42 +++++--
security/keys/keyring.c | 46 ++++++-
security/keys/persistent.c | 4 -
security/keys/process_keys.c | 16 ++-
security/keys/request_key.c | 4 -
security/keys/request_key_auth.c | 2
40 files changed, 699 insertions(+), 510 deletions(-)
create mode 100644 crypto/asymmetric_keys/restrict.c
create mode 100644 include/linux/verification.h
delete mode 100644 include/linux/verify_pefile.h