Re: RFC: New LSM to control usage of x509 certificates

[Eric Snowberg]

> On Oct 20, 2023, at 9:05 AM, Mickaël Salaün <mic@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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.