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: <e0e7c0971d42e45c7b4641bd58cb7ea20b36e2e1.camel@linux.ibm.com>
Date: Fri, 28 Feb 2025 12:18:05 -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 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:
> > > 
> > > 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