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 for Android: free password hash cracker in your pocket

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

Message-ID: <72F52F71-C7F3-402D-8441-3D636A093FE8@oracle.com>
Date: Fri, 3 Jan 2025 23:14:11 +0000
From: Eric Snowberg <eric.snowberg@...cle.com>
To: Mimi Zohar <zohar@...ux.ibm.com>
CC: "open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        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>, Jarkko Sakkinen <jarkko@...nel.org>,
        Paul Moore
	<paul@...l-moore.com>, 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

Hi Mimi,

> On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> 
> On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
>> Motivation:
>> 
>> Each end-user has their own security threat model. What is important to one
>> end-user may not be important to another. There is not a right or wrong threat
>> model.
>> 
>> A common request made when adding new kernel changes that could impact the
>> threat model around system kernel keys is to add additional Kconfig options.
>> As kernel developers, it is challenging to both add and keep track of all the
>> Kconfig options around security features that may limit or restrict
>> system key usage.  It is also difficult for a general purpose distro to take
>> advantage of some of these features, since it may prevent some users from
>> executing their workload.
>> 
>> It is the author's belief that it is better left up to the end-user on how
>> kernel keys should be used within their system.
>> 
>> Throughout the Linux kernel, key usage is tracked when doing signature
>> verification with keys contained within one of the system keyrings;  however,
>> there isn't a way for the end-user to enforce this usage.  This series gives the
>> end-user the ability to configure key usage based on their threat model.
>> Having the ability to enforce key usage also improves security by reducing the
>> attack surface should a system key be compromised. It allows new features to be
>> added without the need for additional Kconfig options for fear of changing the
>> end-user's threat model. It also allows a distro to build a kernel that suits
>> various end-user's needs without resorting to selecting Kconfig options with
>> the least restrictive security options.
> 
> The motivation for this patch set is convincing and addresses limiting the usage
> of keys loaded directly or indirectly onto the system trusted keyrings - 
> .builtin, .machine, and .secondary_trusted_keys keyrings.  Pre-loading the build
> time ephemeral kernel module signing key is a nice improvement from the previous
> versions.  

Apologies for the delayed response and thanks for your feedback on this 
and the other patches you reviewed in the series.

> My main concern is not with Clavis per-se, but that the LSM
> infrastructure allows configuring all the LSMs, but enabling at build time and
> modifying at runtime a subset of them.  Without Clavis enabled, nothing changes
> - any key on the system trusted keyrings remains usable for any purpose.  With
> the current LSM design, the end user security threat model cannot be guaranteed.

I went in the direction of creating a new LSM based on this discussion [1].  
I was hoping to get some feedback from Paul, since I believe I have 
addressed the guidelines for a new LSM.  Currently, the Clavis LSM only 
adds a single LSM hook.  To address your concern, maybe Clavis shouldn't 
be a LSM?  Possibly it could live in the keyring code on its own.

1. https://lkml.org/lkml/2023/10/5/312