Message-ID: <049a04b2e07e9e984ada32277cbbde42bdf7bb1b.camel@linux.ibm.com>
Date: Tue, 04 Mar 2025 20:49:29 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Paul Moore <paul@...l-moore.com>
Cc: Eric Snowberg <eric.snowberg@...cle.com>,
        David Howells
 <dhowells@...hat.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        "open
 list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>,
        David
 Woodhouse <dwmw2@...radead.org>,
        "herbert@...dor.apana.org.au"
 <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Ard Biesheuvel <ardb@...nel.org>, James Morris <jmorris@...ei.org>,
        "Serge
 E. Hallyn" <serge@...lyn.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        Mickaël Salaün <mic@...ikod.net>,
        "casey@...aufler-ca.com" <casey@...aufler-ca.com>,
        Stefan Berger
 <stefanb@...ux.ibm.com>,
        "ebiggers@...nel.org" <ebiggers@...nel.org>,
        Randy
 Dunlap <rdunlap@...radead.org>,
        open list <linux-kernel@...r.kernel.org>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>
Subject: Re: [RFC PATCH v3 00/13] Clavis LSM

On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@...ux.ibm.com> wrote:
> > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@...ux.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@...ux.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.
> 
> Yep.
> 
> > Only a
> > particular key should be used to verify the file signatures for a particular
> > application.
> 
> That's definitely one access control policy, but I can also envision a
> scenario where I have just one keyring for application signatures with
> multiple keys from multiple vendors.

Having a single keyring with keys from multiple software vendors is the status
quo.

> 
> > 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.
> 
> Which is fine, but like I said earlier, it makes far more sense to me
> to move towards usage oriented keyrings and then apply whatever
> additional access control granularity is required to meet a given
> scenario.

Since you didn't agree with my example of "usage oriented keyrings", please
provide an example.

> 
> It's also worth (re)mentioning that what makes Clavis not-a-LSM in my
> mind is how it is implemented, not necessarily its security goals.  If
> Clavis were to be implemented in such a way that it only relied on
> security/LSM blobs and not keys/keyrings it might be more suitable.
> 
> > > > > 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.
> 
> Yep.
> 
> > 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.
> 
> It all depends on what your goals are, but like I said above, it
> really seems to me like this is a good first step which can be
> followed up with additional granularity.

Without a concrete example of "usage oriented keyrings", it's hard to understand
why "additional" granularity should be deferred.  From my perspective,
"additional" granularity is the main issue.

Mimi

Powered by blists - more mailing lists