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

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

On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 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:
> 
> ...
> 
> > 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.
> 
> Perhaps we're not understanding each other, but my understanding of
> the above three scenarios is that they are all examples of signed
> applications where something (likely something in the kernel like IMA)
> verifies the signature on the application.  While there are going to
> be differing numbers of keys in each of the three scenarios, I believe
> they would all be on/linked-to the same usage oriented keyring as they
> all share the same usage: application signatures.

Yes they're all verifying file signatures, but the software packages are from
different sources (e.g. distro, chrome), signed by different keys.  Only a
particular key should be used to verify the file signatures for a particular
application.  The scenarios, described above, are the ratio of distro/single
entity vs. non distro/single entity signed packages, which would correspond to
the number of keyrings.

Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image,
firmware, etc).  It's a good start, but even this probably is not fine enough
granularity.

> 
> > > 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.
> 
> Unfortunately I think we're getting a little ambiguous with how we are
> using the word "trust".  Just as "security" can mean different things
> depending on context, so can "trust" as the qualities we are trusting
> will vary depending on context.  I'll leave it at that for now as I
> believe we are talking about different things in the paragraphs above.
> 
> Regardless, I'll also say this regarding Clavis and key/keyring access
> controls - as implemented, Clavis doesn't look like a LSM to me for
> the reasons already given.  If all of the various keys subsystem
> maintainers believe it is the Right Thing To Do inside the keys
> subsystem then it isn't my place to have a say in that.  I personally
> believe that doing the work to support usage oriented keyrings before,
> or while, implementing a Clavis-like mechanism is the better option,
> but that is a decision for you and the other key maintainers.

"Usage oriented keyrings" similarly implies any key on a particular keyring is
acceptable.  Without understanding what you mean by "usage oriented keyrings", I
would assume it would work initially, but eventually it too will not be fine
enough granularity.

Mimi