From: David Howells <dhowells@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: dhowells@redhat.com, "Mark D. Baushke" <mdb@juniper.net>,
James Morris <jmorris@namei.org>,
Marcel Holtmann <marcel@holtmann.org>,
petkan@mip-labs.com, linux-security-module@vger.kernel.org,
keyrings@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring
Date: Tue, 12 Jan 2016 10:08:39 +0000 [thread overview]
Message-ID: <31422.1452593319@warthog.procyon.org.uk> (raw)
In-Reply-To: <1452569755.4776.69.camel@linux.vnet.ibm.com>
Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> The IMA MOK and blacklist are restricted to "public_key_restrict_link".
> Does this only allow keys signed by keys on the respective keyring or
> also by the system keyring?
As my patches stand, the following are implemented:
(1) public_key_restrict_link() restricts to asymmetric keys that are signed
by a CA in the specified keyring. It returns -ENOKEY if no matching key
is found rather than -EKEYREJECTED, however, so you can call it several
times for different keyrings. -EKEYREJECTED is only returned if a
signature check fails. This is used by the following two functions.
(2) restrict_link_by_system_trusted() restricts to asymmetric keys that are
signed by a CA in the system keyring. This ignores the keyring argument
it is given.
Note that the system_trusted_keyring is then no longer exported because
verify_pkcs7_signature() is also in certs/system_keyring.c and uses that
by default if NULL is passed.
(3) restrict_link_by_ima_mok() restricts to asymmetric keys signed by a CA in
either .system_keyring or .ima_mok.
So the trusted keyrings are then restricted as follows:
(1) .system_keyring uses restrict_link_by_system_trusted() - though it lacks
any sort of write permission, so it's currently moot. It could just as
well be replaced with a function that just returns -EPERM.
(2) .ima_mok should be using restrict_link_by_system_trusted(), but I failed
to update this when I split the public_key_restrict_link() function.
I've updated this in my patch. This would then be correct according to
Petko's commit log:
To successfully import a key into .ima_mok it must be signed by a
key which CA is in .system keyring.
However, from what Petko says, this is wrong and it should instead be
using restrict_link_by_ima_mok().
(3) .ima_blacklist should be using restrict_link_by_system_trusted() also.
I've no idea whether additions to this should be permitted by keys in
.ima_mok also.
(4) .ima uses restrict_link_by_ima_mok(), as per:
On turn any key that needs to go in .ima keyring must be signed by CA
in either .system or .ima_mok keyrings.
(5) .evm is not restricted by my patches. This is a mistake on my part - but
I'm not sure what the restriction actually needs to be as it's not
mentioned in Petko's commit message. Presumably it needs the same as
.ima.
David
next prev parent reply other threads:[~2016-01-12 10:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 13:45 [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring David Howells
2016-01-07 0:04 ` James Morris
2016-01-07 0:34 ` David Howells
2016-01-07 2:13 ` Mimi Zohar
2016-01-07 3:28 ` Mimi Zohar
2016-01-07 15:31 ` Mimi Zohar
2016-01-10 10:36 ` James Morris
2016-01-10 13:26 ` Mimi Zohar
2016-01-10 17:46 ` David Howells
2016-01-10 20:33 ` David Howells
2016-01-10 23:55 ` Mimi Zohar
2016-01-12 0:44 ` David Howells
2016-01-12 1:28 ` Mark D. Baushke
2016-01-12 2:03 ` David Howells
2016-01-12 2:25 ` Mark D. Baushke
2016-01-12 3:35 ` Mimi Zohar
2016-01-12 10:08 ` David Howells [this message]
2016-01-12 13:21 ` Mimi Zohar
2016-01-12 13:55 ` David Howells
2016-01-12 15:17 ` Mimi Zohar
2016-01-12 15:56 ` David Howells
2016-01-12 16:02 ` Mimi Zohar
2016-01-12 14:11 ` Petko Manolov
2016-01-10 20:33 ` Petko Manolov
2016-01-12 1:38 ` David Howells
2016-01-12 16:14 ` Petko Manolov
2016-01-12 17:08 ` David Howells
2016-01-13 16:31 ` Petko Manolov
2016-01-13 17:51 ` Mimi Zohar
2016-01-13 18:01 ` Petko Manolov
2016-01-13 18:19 ` David Howells
2016-01-13 18:35 ` Petko Manolov
2016-01-13 18:56 ` Mimi Zohar
2016-01-13 19:19 ` 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=31422.1452593319@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=mdb@juniper.net \
--cc=petkan@mip-labs.com \
--cc=zohar@linux.vnet.ibm.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