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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhRrko_CdZJg81=s-ShGfusaJqhvrX8+R6STPbMhpnEwCQ@mail.gmail.com>
Date: Tue, 4 Mar 2025 21:09:31 -0500
From: Paul Moore <paul@...l-moore.com>
To: Mimi Zohar <zohar@...ux.ibm.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, Mar 4, 2025 at 8:50 PM Mimi Zohar <zohar@...ux.ibm.com> wrote:
> 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.

A single keyring with keys from multiple vendors does happen today
yes, but there is no separation based on how those keys are used, e.g.
separate application signature and kernel module signature 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.
> >
> > 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.

I have.

-- 
paul-moore.com