Message-ID: <A3A29FB9-E015-4C87-B5F0-190A4C779CB3@oracle.com>
Date: Thu, 20 Mar 2025 16:24:15 +0000
From: Eric Snowberg <eric.snowberg@...cle.com>
To: Paul Moore <paul@...l-moore.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 Mar 6, 2025, at 7:46 PM, Paul Moore <paul@...l-moore.com> wrote:
> 
> On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@...cle.com> wrote:
>>> On Mar 5, 2025, at 6:12 PM, Paul Moore <paul@...l-moore.com> wrote:
>>> 
>>> 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).
>> 
>> Does this mean Microsoft will begin signing shims in the future without
>> the lockdown requirement?
> 
> That's not a question I can answer, you'll need to discuss that with the UEFI SB people.

Based on your previous lockdown comments, I thought you might have 
some new information.  Having lockdown enforcement has always been 
a requirement to get a shim signed by Microsoft. 

The alternative "usage-oriented keyring" approach you've suggested 
wouldn't align with the threat model that lockdown aims to achieve.  For 
a distro-based kernel, I don't see the value in pursuing such an approach. 
For someone compiling their own kernel and not using a distro kernel, 
they could compile in their own keys.  With Clavis, I attempted to develop 
an approach that would meet the lockdown threat model requirements 
while allowing the end user to control key usage as they deem fit.

Powered by blists - more mailing lists