Message-ID: <20160119113026.23238.4498.stgit@warthog.procyon.org.uk>
Date:	Tue, 19 Jan 2016 11:30:26 +0000
From:	David Howells <dhowells@...hat.com>
To:	zohar@...ux.vnet.ibm.com
Cc:	dhowells@...hat.com, linux-security-module@...r.kernel.org,
	keyrings@...r.kernel.org, petkan@...-labs.com,
	linux-kernel@...r.kernel.org
Subject: [RFC PATCH 00/20] KEYS: Restrict additions to 'trusted' keyrings
 [ver #2]


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

Powered by blists - more mailing lists