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: <1A222B45-FCC4-4BBD-8E17-D92697FE467D@oracle.com>
Date: Wed, 5 Mar 2025 21:29:44 +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 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.

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?

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.