From: Eric Snowberg <eric.snowberg@oracle.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: Paul Moore <paul@paul-moore.com>,
Mimi Zohar <zohar@linux.ibm.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
David Howells <dhowells@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Kanth Ghatraju <kanth.ghatraju@oracle.com>,
Konrad Wilk <konrad.wilk@oracle.com>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
KP Singh <kpsingh@kernel.org>
Subject: Re: RFC: New LSM to control usage of x509 certificates
Date: Fri, 20 Oct 2023 15:53:22 +0000 [thread overview]
Message-ID: <8096FB15-1766-4C0B-BCE0-BB520BAAC0B7@oracle.com> (raw)
In-Reply-To: <20231020.wae7johZae2i@digikod.net>
> On Oct 20, 2023, at 9:05 AM, Mickaël Salaün <mic@digikod.net> wrote:
>
> On Thu, Oct 19, 2023 at 11:08:38PM +0000, Eric Snowberg wrote:
>>
>>
>>> On Oct 19, 2023, at 3:12 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>>
>>> The more flexible approach would be to not hardcode any policy in the
>>> kernel but let sysadmins define their own, including OIDs. We "just"
>>> need to find an adequate configuration scheme to define these
>>> constraints.
>>
>> Also, with the flexible approach, the policy would need to be given to the
>> kernel before any kernel module loads, fs-verity starts, or anything dealing
>> with digital signature based IMA runs, etc. With hardcoded policies this
>> could be setup from the kernel command line or be set from a Kconfig.
>> I assume with a flexible approach, this would need to come in early within
>> the initram?
>
> Yes, either the cmdline and/or the initramfs.
>
>>
>>> We already have an ASN.1 parser in the kernel, so we might
>>> want to leverage that to match a certificate.
>>
>> We have the parser, however after parsing the certificate we do not
>> retain all the information within it. Some of the recent changes I have
>> done required modifications to the public_key struct. If there isn’t any
>> type of hard coded policy, what would be the reception of retaining the
>> entire cert within the kernel?
>
> I think it would make sense to have a default policy loaded at boot
> time, then load and take into account new pieces of policies at run
> time, but only parse/tag/assign a role to certificates/keys when they
> are loaded.
Many keys are loaded into the kernel before the initram is used. This
includes: builtin, platform (UEFI DB), and machine (MOK). I believe
these are the keys of most interest for controlling usage. By not retaining
all the attributes, I’m not sure how a useful filtering policy could be
implemented afterwards. Do you have any ideas?
Also, for revocation, today we allow any system key to vouch for inclusion
into the blacklist keyring. Shouldn’t only the CA with the correct attributes
that originally signed the key be able to do this? If all attributes were retained
this could also be possible. There is a similar issue with keys added to the
secondary keyring. Any key linked to the secondary can do the vouching
for inclusion and usage is ignored. If a policy is added afterwards to enforce
this, we don’t have all the information necessary to do the enforcement.
next prev parent reply other threads:[~2023-10-20 15:53 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 21:34 [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring Eric Snowberg
2023-09-11 13:29 ` Mimi Zohar
2023-09-11 16:51 ` Mickaël Salaün
2023-09-11 22:17 ` Eric Snowberg
2023-09-11 23:08 ` Mimi Zohar
2023-09-12 2:00 ` Eric Snowberg
2023-09-12 11:54 ` Mimi Zohar
2023-09-12 17:11 ` Eric Snowberg
2023-09-12 22:47 ` Mimi Zohar
2023-09-13 2:40 ` Eric Snowberg
2023-09-13 10:21 ` Mickaël Salaün
2023-09-13 22:29 ` Eric Snowberg
2023-09-14 8:34 ` Mickaël Salaün
2023-10-05 10:32 ` RFC: New LSM to control usage of x509 certificates Mickaël Salaün
2023-10-05 14:05 ` Paul Moore
2023-10-17 13:39 ` Mimi Zohar
2023-10-17 15:45 ` Paul Moore
2023-10-17 17:08 ` Mimi Zohar
2023-10-17 17:29 ` Paul Moore
2023-10-17 17:58 ` Mimi Zohar
2023-10-17 18:51 ` Paul Moore
2023-10-17 19:34 ` Eric Snowberg
2023-10-18 14:14 ` Mickaël Salaün
2023-10-18 23:12 ` Eric Snowberg
2023-10-19 9:12 ` Mickaël Salaün
2023-10-19 23:08 ` Eric Snowberg
2023-10-20 15:05 ` Mickaël Salaün
2023-10-20 15:26 ` Roberto Sassu
2023-10-20 15:53 ` Eric Snowberg [this message]
2023-09-11 22:04 ` [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring Jarkko Sakkinen
2023-09-11 22:23 ` Eric Snowberg
2023-09-11 22:01 ` Jarkko Sakkinen
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=8096FB15-1766-4C0B-BCE0-BB520BAAC0B7@oracle.com \
--to=eric.snowberg@oracle.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=jarkko@kernel.org \
--cc=kanth.ghatraju@oracle.com \
--cc=keyrings@vger.kernel.org \
--cc=konrad.wilk@oracle.com \
--cc=kpsingh@kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.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 read-only IMAP folder(s) and NNTP newsgroup(s).