Message-ID: <CAHC9VhTObTee95SwZ+C4EwPotovE9R3vy0gVXf+kATtP3vfXrg@mail.gmail.com>
Date: Wed, 5 Mar 2025 20:12:39 -0500
From: Paul Moore <paul@...l-moore.com>
To: Eric Snowberg <eric.snowberg@...cle.com>
Cc: Mimi Zohar <zohar@...ux.ibm.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 Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@...cle.com> wrote:
> > On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@...l-moore.com> wrote:
> > On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@...cle.com> wrote:
> >>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@...l-moore.com> wrote:
> >>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@...cle.com> wrote:
> >>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@...l-moore.com> 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 intent is not to limit ourselves to the source of the key.  The main
> >>>> point of Clavis is to allow the end-user to determine what kernel keys
> >>>> they want to trust and for what purpose, irrespective of the originating
> >>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
> >>>> go back in time, individual keyrings could be created that are oriented
> >>>> toward usage.   The idea for introducing Clavis is to bridge what we
> >>>> have today with kernel keys and allow them to be usage based.
> >>>
> >>> While it is unlikely that the current well known keyrings could be
> >>> removed, I see no reason why new usage oriented keyrings could not be
> >>> introduced.  We've seen far more significant shifts in the kernel over
> >>> the years.
> >>
> >> Could you further clarify how a usage oriented keyring would work?  For
> >> example, if a kernel module keyring was added, how would the end-user
> >> add keys to it while maintaining a root of trust?
> >
> > Consider it an exercise left to the reader :)
> >
> > I imagine there are different ways one could do that, either using
> > traditional user/group/capability permissions and/or LSM permissions,
> > it would depend on the environment and the security goals of the
> > overall system.
>
> These keys are used by the Lockdown LSM to provide signature
> validation.
>
> I realize the contents that follow in this paragraph is outside the
> boundary of mainline kernel code.  Every distro that wants their
> shim signed must explain how their kernel enforces lockdown
> mode.  The minimum requirement is lockdown in integrity mode.
> Also, the expectation is lockdown enforcement continues on
> through a kexec.

I personally find it very amusing the UEFI Secure Boot shim is reliant
on an unmaintained and only marginally supported LSM, Lockdown.  Has
anyone recently verified that Lockdown's protections are still intact
and comprehensive enough to be worthwhile?  Sorry, this is a bit of a
digression, but since you were the one to bring up Lockdown I thought
it would be important to mention that I don't have much faith that it
is still working to the same level as it originally was intended.  I
have a TODO list item to draft a policy around deprecating
unmaintained LSMs after an extended period of time, and once that is
in place if we don't have a qualified maintainer for Lockdown it will
likely fall into the deprecation process (whatever that may be).

> When in lockdown integrity mode, features that allow the kernel
> to be modified at runtime are disabled.  How would what you have
> suggested above adhere to these goals?

For starters, verify that Lockdown is still comprehensive enough to
satisfy these requirements on a modern Linux kernel.  After that has
been done, find someone with some kernel experience to step up and
maintain Lockdown.  Finally, put a mechanism in place so that
someone/something is regularly evaluating changes in the upstream
kernel to ensure that Lockdown is still able to achieve its security
goals.

After all that, then you can start worrying about keys.

> The point of the Clavis LSM is to use the root of trust provided to
> the kernel prior to it booting. This maintains the lockdown integrity
> goals, while also giving the end-user the ability to determine how
> kernel keys are used.

-- 
paul-moore.com

Powered by blists - more mailing lists