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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHC9VhQzALRBZ3mMDL5fmdJepjeHLUz=Tm4xtoLJrL8R6Y0QKg@mail.gmail.com>
Date: Tue, 4 Mar 2025 21:24:12 -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 9:20 PM Mimi Zohar <zohar@...ux.ibm.com> wrote:
> On Tue, 2025-03-04 at 21:09 -0500, Paul Moore wrote:
> > 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.
>
> As soon as you add multiple vendors keys on the kernel module signature keyring,
> you'll need finer grained access control.

Maybe.  It depends on your security policy, some solutions might be
okay with keyring level access control granularity, others may want
finer grained control.

-- 
paul-moore.com