From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted
Date: Wed, 21 Oct 2015 13:02:48 -0400 [thread overview]
Message-ID: <1445446968.2459.272.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20151021151314.4583.90962.stgit@warthog.procyon.org.uk>
On Wed, 2015-10-21 at 16:13 +0100, 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 is removed. The kernel may add
> implicitly trusted keys to a trusted-only keyring by asserting
> KEY_ALLOC_TRUSTED when the key is created,
Ok, but only the x509 certificates built into the kernel image should be
automatically trusted and can be added to a trusted keyring, because the
kernel itself was signed (and verified). These certificates extend the
(UEFI) certificate chain of trust that is rooted in hardware to the OS.
Other keys that the kernel reads and loads should not automatically be
trusted (eg. ima_load_x509). They need to be validated against a
trusted key.
> but otherwise the key will only
> be allowed to be added to the keyring if it can be verified by a key
> already in that keyring. 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.
We already went down this path of "transitive trust" back when we first
introduced the concept of trusted keys and keyrings. Just because a
key is on a trusted keyring, doesn't imply that it should be permitted
to load other keys on the same trusted keyring. In the case of
IMA-appraisal, the key should only be used to verify the file data
signature, not other keys.
The trusted keys used for verifying other certificates should be stored
on a separate keyring, not the target keyring. Petko's patches define
a new IMA keyring named .ima_mok for this purpose.
Mimi
> 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-20151021
>
next prev parent reply other threads:[~2015-10-21 17:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-21 15:13 [PATCH 00/10] KEYS: Change how keys are determined to be trusted David Howells
2015-10-21 15:13 ` [PATCH 01/10] KEYS: Generalise system_verify_data() to provide access to internal content David Howells
2015-10-21 15:13 ` [PATCH 02/10] PKCS#7: Make trust determination dependent on contents of trust keyring David Howells
2015-10-21 15:13 ` [PATCH 03/10] KEYS: Add facility to check key trustworthiness upon link creation David Howells
2015-10-21 15:13 ` [PATCH 04/10] KEYS: Allow authentication data to be stored in an asymmetric key David Howells
2015-10-21 15:14 ` [PATCH 05/10] KEYS: Add identifier pointers to public_key_signature struct David Howells
2015-10-21 15:14 ` [PATCH 06/10] X.509: Retain the key verification data David Howells
2015-10-21 15:14 ` [PATCH 07/10] X.509: Extract signature digest and make self-signed cert checks earlier David Howells
2015-10-21 15:14 ` [PATCH 08/10] PKCS#7: Make the signature a pointer rather than embedding it David Howells
2015-10-21 15:14 ` [PATCH 09/10] X.509: Move the trust validation code out to its own file David Howells
2015-10-21 15:14 ` [PATCH 10/10] KEYS: Move the point of trust determination to __key_link() David Howells
2015-10-21 17:02 ` Mimi Zohar [this message]
2015-10-21 17:21 ` [PATCH 00/10] KEYS: Change how keys are determined to be trusted Josh Boyer
2015-10-21 18:11 ` Mimi Zohar
2015-10-21 18:21 ` Josh Boyer
2015-10-21 18:33 ` Mimi Zohar
2015-10-21 18:48 ` Petko Manolov
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=1445446968.2459.272.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).