From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
petkan@mip-labs.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/15] KEYS: Restrict additions to 'trusted' keyrings
Date: Fri, 08 Jan 2016 13:54:24 -0500 [thread overview]
Message-ID: <1452279264.2651.7.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160108183319.25960.49807.stgit@warthog.procyon.org.uk>
On Fri, 2016-01-08 at 18:33 +0000, David Howells wrote:
> Here's a set of patches that changes how keys are determined to be trusted
> - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
> it. A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
> indicates that only keys with this flag set may be added to that keyring.
>
> Further, any time an X.509 certificate is instantiated without this flag
> set, the certificate is judged against the contents of the system trusted
> keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
>
> With these patches, KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed.
>
> The kernel may add implicitly trusted keys to a trusted-only keyring by
> asserting KEY_ALLOC_BYPASS_RESTRICTION when the key is created, but
> otherwise the key will only be allowed to be added to the keyring if it can
> be verified. The system trusted keyring is not then special in this sense
> and other trusted keyrings can be set up that are wholly independent of it.
In order to have a certificate chain of trust on any of these trusted
keyrings, the system keyring needs to be special. Even if we permit
transitive trust, meaning keys on a keyring can be used to validate
other keys being added to the same keyring, the first key added to a
trusted keyring needs to be vetted against something. That something
needs to be the builtin keys on the system keyring.
Mimi
> Each keyring can be given a vetting function that allows it to reject
> attempts to add keys to that keyring based on the type and payload of the
> new key. This can be set separately for each keyring.
>
> To make this work, we have to retain sufficient data from the X.509
> certificate that we can then verify the signature at need.
>
> The patches can be found here also:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-trust
>
> and are tagged with:
>
> keys-trust-20160108
>
> David
> ---
> David Howells (15):
> X.509: Partially revert patch to add validation against IMA MOK keyring
> 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 an alloc flag to convey the builtinness of a key
> 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
>
>
> Documentation/security/keys.txt | 14 +
> arch/x86/kernel/kexec-bzimage64.c | 18 --
> certs/system_keyring.c | 72 +++++--
> 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 | 64 +++---
> crypto/asymmetric_keys/pkcs7_parser.c | 59 +++---
> crypto/asymmetric_keys/pkcs7_parser.h | 11 -
> crypto/asymmetric_keys/pkcs7_trust.c | 44 ++--
> crypto/asymmetric_keys/pkcs7_verify.c | 109 ++++------
> crypto/asymmetric_keys/public_key.c | 24 ++
> crypto/asymmetric_keys/public_key.h | 6 +
> crypto/asymmetric_keys/public_key_trust.c | 206 ++++++++++++++++++++
> 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 | 12 -
> crypto/asymmetric_keys/x509_public_key.c | 304 ++++++++---------------------
> 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 | 20 --
> include/linux/key.h | 40 +++-
> 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 | 34 +++
> security/integrity/digsig_asymmetric.c | 5
> security/integrity/ima/ima_mok.c | 9 -
> security/keys/key.c | 43 +++-
> 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
> 43 files changed, 804 insertions(+), 610 deletions(-)
> 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
>
next prev parent reply other threads:[~2016-01-08 18:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-08 18:33 [RFC PATCH 00/15] KEYS: Restrict additions to 'trusted' keyrings David Howells
2016-01-08 18:33 ` [RFC PATCH 01/15] X.509: Partially revert patch to add validation against IMA MOK keyring David Howells
2016-01-08 18:33 ` [RFC PATCH 02/15] X.509: Don't treat self-signed keys specially David Howells
2016-01-08 18:33 ` [RFC PATCH 03/15] KEYS: Generalise system_verify_data() to provide access to internal content David Howells
2016-01-08 18:33 ` [RFC PATCH 04/15] PKCS#7: Make trust determination dependent on contents of trust keyring David Howells
2016-01-08 18:33 ` [RFC PATCH 05/15] KEYS: Add an alloc flag to convey the builtinness of a key David Howells
2016-01-08 18:34 ` [RFC PATCH 06/15] KEYS: Add a facility to restrict new links into a keyring David Howells
2016-01-08 18:34 ` [RFC PATCH 07/15] KEYS: Allow authentication data to be stored in an asymmetric key David Howells
2016-01-08 18:34 ` [RFC PATCH 08/15] KEYS: Add identifier pointers to public_key_signature struct David Howells
2016-01-08 18:34 ` [RFC PATCH 09/15] X.509: Retain the key verification data David Howells
2016-01-08 18:34 ` [RFC PATCH 10/15] X.509: Extract signature digest and make self-signed cert checks earlier David Howells
2016-01-08 18:34 ` [RFC PATCH 11/15] PKCS#7: Make the signature a pointer rather than embedding it David Howells
2016-01-08 18:34 ` [RFC PATCH 12/15] X.509: Move the trust validation code out to its own file David Howells
2016-01-08 18:34 ` [RFC PATCH 13/15] KEYS: Generalise x509_request_asymmetric_key() David Howells
2016-01-08 18:35 ` [RFC PATCH 14/15] KEYS: Move the point of trust determination to __key_link() David Howells
2016-01-08 18:35 ` [RFC PATCH 15/15] KEYS: Remove KEY_FLAG_TRUSTED David Howells
2016-01-08 18:54 ` Mimi Zohar [this message]
2016-01-08 19:18 ` [RFC PATCH 00/15] KEYS: Restrict additions to 'trusted' keyrings Mimi Zohar
2016-01-12 0:38 ` David Howells
2016-01-12 2:43 ` Mimi Zohar
2016-01-12 0:37 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1452279264.2651.7.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=petkan@mip-labs.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox