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