Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg <eric.snowberg@oracle.com>]

Hi Mimi,

> On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@linux.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