From: Stefan Berger <stefanb@linux.ibm.com>
To: Eric Snowberg <eric.snowberg@oracle.com>,
Mimi Zohar <zohar@linux.ibm.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
David Howells <dhowells@redhat.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"jmorris@namei.org" <jmorris@namei.org>,
"serge@hallyn.com" <serge@hallyn.com>,
"nayna@linux.ibm.com" <nayna@linux.ibm.com>,
"mic@linux.microsoft.com" <mic@linux.microsoft.com>,
Konrad Wilk <konrad.wilk@oracle.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH 3/4] KEYS: CA link restriction
Date: Wed, 9 Mar 2022 12:12:41 -0500 [thread overview]
Message-ID: <930d970d-0120-d3f0-939a-b5ef3b596318@linux.ibm.com> (raw)
In-Reply-To: <068F32E0-B202-4B20-9DE7-57373EF71BFE@oracle.com>
On 3/8/22 13:02, Eric Snowberg wrote:
>
>
>> On Mar 8, 2022, at 5:45 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>
>> On Mon, 2022-03-07 at 21:31 -0500, Stefan Berger wrote:
>>>
>>> On 3/7/22 18:38, Eric Snowberg wrote:
>>>>
>>>>
>>>>> On Mar 7, 2022, at 4:01 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>
>>>>> On Mon, 2022-03-07 at 18:06 +0000, Eric Snowberg wrote:
>>>>>>
>>>>>>>> diff --git a/crypto/asymmetric_keys/restrict.c b/crypto/asymmetric_keys/restrict.c
>>>>>>>> index 6b1ac5f5896a..49bb2ea7f609 100644
>>>>>>>> --- a/crypto/asymmetric_keys/restrict.c
>>>>>>>> +++ b/crypto/asymmetric_keys/restrict.c
>>>>>>>> @@ -108,6 +108,49 @@ int restrict_link_by_signature(struct key *dest_keyring,
>>>>>>>> return ret;
>>>>>>>> }
>>>>>>>> +/**
>>>>>>>> + * restrict_link_by_ca - Restrict additions to a ring of CA keys
>>>>>>>> + * @dest_keyring: Keyring being linked to.
>>>>>>>> + * @type: The type of key being added.
>>>>>>>> + * @payload: The payload of the new key.
>>>>>>>> + * @trust_keyring: Unused.
>>>>>>>> + *
>>>>>>>> + * Check if the new certificate is a CA. If it is a CA, then mark the new
>>>>>>>> + * certificate as being ok to link.
>>>>>>>
>>>>>>> CA = root CA here, right?
>>>>>>
>>>>>> Yes, I’ll update the comment
>>>>>
>>>>> Updating the comment is not enough. There's an existing function named
>>>>> "x509_check_for_self_signed()" which determines whether the certificate
>>>>> is self-signed.
>>>>
>>>> Originally I tried using that function. However when the restrict link code is called,
>>>> all the necessary x509 information is no longer available. The code in
>>>> restrict_link_by_ca is basically doing the equivalent to x509_check_for_self_signed.
>>>> After verifying the cert has the CA flag set, the call to public_key_verify_signature
>>>> validates the cert is self signed.
>>>>
>>> Isn't x509_cert_parse() being called as part of parsing the certificate?
>>> If so, it seems to check for a self-signed certificate every time. You
>>> could add something like the following to x509_check_for_self_signed(cert):
>>> pub->x509_self_signed = cert->self_signed = true;
>>>
>>> This could then reduce the function in 3/4 to something like:
>>>
>>> return payload->data[asym_crypto]->x509_self_signed;
>
> When I was studying the restriction code, before writing this patch, it looked like
> it was written from the standpoint to be as generic as possible. All code contained
> within it works on either a public_key_signature or a public_key. I had assumed it
> was written this way to be used with different asymmetrical key types now and in
> the future. I called the public_key_verify_signature function instead of interrogating
> the x509 payload to keep in line with what I thought was the original design. Let me
> know if I should be carrying x509 code in here to make the change above.
It does not seem right if there were two functions trying to determine
whether an x509 cert is self-signed. The existing is invoked as part of
loading a key onto the machine keyring from what I can see. It has
access to more data about the cert and therefore can do stronger tests,
yours doesn't have access to the data. So I guess I would remember in a
boolean in the public key structure that the x509 cert it comes from was
self signed following the existing test. Key in your function may be
that that payload->data[] array is guaranteed to be from the x509 cert
as set in x509_key_preparse().
https://elixir.bootlin.com/linux/v5.17-rc7/source/crypto/asymmetric_keys/x509_public_key.c#L236
StefanIt does not seem right if there were two functions trying to
determine whether an x509 cert is self-signed. The existing is invoked
as part of loading a key onto the machine keyring from what I can see.
It has access to more data about the cert and therefore can do stronger
tests, yours doesn't have access to the data. So I guess I would
remember in a boolean in the public key structure that the x509 cert it
comes from was self signed following the existing test. Key in your
function may be that that payload->data[] array is guaranteed to be from
the x509 cert as set in x509_key_preparse().
https://elixir.bootlin.com/linux/v5.17-rc7/source/crypto/asymmetric_keys/x509_public_key.c#L236
Stefan
next prev parent reply other threads:[~2022-03-09 17:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 17:36 [PATCH 0/4] Add CA enforcement in the machine keyring Eric Snowberg
2022-03-01 17:36 ` [PATCH 1/4] KEYS: Create static version of public_key_verify_signature Eric Snowberg
2022-03-01 17:36 ` [PATCH 2/4] X.509: Parse Basic Constraints for CA Eric Snowberg
2022-03-04 15:10 ` Stefan Berger
2022-03-07 18:02 ` Eric Snowberg
2022-03-01 17:36 ` [PATCH 3/4] KEYS: CA link restriction Eric Snowberg
2022-03-04 15:28 ` Stefan Berger
2022-03-07 18:06 ` Eric Snowberg
2022-03-07 23:01 ` Mimi Zohar
2022-03-07 23:38 ` Eric Snowberg
2022-03-08 2:31 ` Stefan Berger
2022-03-08 12:45 ` Mimi Zohar
2022-03-08 13:56 ` Stefan Berger
2022-03-08 18:02 ` Eric Snowberg
2022-03-09 17:12 ` Stefan Berger [this message]
2022-03-09 17:17 ` Stefan Berger
2022-03-09 18:13 ` Eric Snowberg
2022-03-09 19:02 ` Stefan Berger
2022-03-11 18:44 ` Eric Snowberg
2022-03-11 20:23 ` Stefan Berger
2022-03-14 12:00 ` Stefan Berger
2022-03-09 17:33 ` Mimi Zohar
2022-03-01 17:36 ` [PATCH 4/4] integrity: CA enforcement in machine keyring Eric Snowberg
2022-03-04 23:19 ` Stefan Berger
2022-03-07 18:13 ` Eric Snowberg
2022-03-07 18:36 ` Stefan Berger
2022-03-07 18:48 ` Eric Snowberg
2022-03-06 23:33 ` [PATCH 0/4] Add CA enforcement in the " Mimi Zohar
2022-03-07 18:55 ` Eric Snowberg
2022-03-09 18:43 ` Mimi Zohar
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=930d970d-0120-d3f0-939a-b5ef3b596318@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=eric.snowberg@oracle.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@linux.microsoft.com \
--cc=nayna@linux.ibm.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.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;
as well as URLs for NNTP newsgroup(s).