Re: [RFC PATCH v3 00/13] Clavis LSM

[Mimi Zohar <zohar@linux.ibm.com>]

On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > 
> > > I'd still also like to see some discussion about moving towards the
> > > addition of keyrings oriented towards usage instead of limiting
> > > ourselves to keyrings that are oriented on the source of the keys.
> > > Perhaps I'm missing some important detail which makes this
> > > impractical, but it seems like an obvious improvement to me and would
> > > go a long way towards solving some of the problems that we typically
> > > see with kernel keys.
> > 
> > The proliferation of keyrings won't solve the key usage problem for IMA-
> > appraisal.  IMA-appraisal can be used to verify the kexec image, kernel modules,
> > firwmare, etc, but it also verifies file signatures contained in userspace
> > packages.
> 
> To be clear I don't think the usage oriented keyring idea will solve
> every keyring problem, but it seems like it solves a fair number of
> things that I've heard lately.
> 
> >  To support the latter case, keyrings would need to be application
> > specific.  (This version of Clavis doesn't solve the latter key usage for IMA-
> > appraisal either.)
> 
> Application specific keyrings are more-or-less what I've been trying
> to describe.

Ok, let's go through different scenarios to see if it would scale.

Scenario 1: Mostly distro signed userspace applications, minimum number of
developer, customer, 3rd party applications.

Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
same party.

Scenario 3: extreme case - every application signed by different party.

With the minimum case, there would probably be a default key or sets of
permissible keys.  In the extreme case, the number of keyrings would be
equivalent to the number of application/software packages.

> 
> > The keys baked into the kernel are trusted because the kernel itself was signed
> > and verified (secure boot).  Anyone building a kernel can build a key into the
> > kernel image, which establishes a "root of trust".  That key can then be used to
> > verify and load other keys onto the IMA keyring.
> 
> Sure, I'm not saying that trust isn't important, and that there are
> varying levels of trust.  My argument is that having additional,
> usage/application oriented keyrings which contain links back to keys
> imported and stored in the traditional trust oriented keyrings could
> neatly solve a number of keyring access control issues.
> 
> > The problem is how to safely establish a root of trust without baking the key
> > into the kernel image and then limiting that trust to specific usages or
> > applications.
> 
> My takeaway from Clavis was that it was more about establishing a set
> of access controls around keys already present in the keyrings and my
> comments about usage/spplication oriented keyrings have been in that
> context.  While the access control policy, regardless of how it is
> implemented, should no doubt incorporate the trust placed in the
> individual keys, how that trust is established is a separate issue
> from access control as far as I'm concerned.

Clavis defined both a mechanism for establishing trust and access control rules.

Clavis defined a single Clavis key to establish trust.  The Clavis policy rules
were signed by the Clavis key.  The Clavis policy rules defined the access
control.

Mimi