On Fri, Jan 3, 2025 at 6:14 PM Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote: > > On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: ... > > 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. My turn to apologize for a very late reply, you've been very patient and I appreciate that. With respect to Mimi's concerns about disabling Clavis, or any LSM for that matter, at runtime, doing so requires the ability to modify the kernel's command line. I would argue that if a user can manipulate the kernel command line there are more serious issues that need to be dealt with first. Any user who is seriously concerned about the state of their system should have some mechanism in place to ensure that the kernel command line is not subject to tampering; thankfully there are efforts underway to help bring tamper resistant command lines to a larger audience (the UKI work). I can't remember if anyone has ever brought this up on-list, and if so what objections there may have been, but I've always wondered if the real problem is simply that we use a handful of keyrings for far too many things inside the kernel. What terrible things would need to be overcome if we created additional keyrings based on usage, e.g. ".modulesigning", and used these task specific keyrings instead of the existing source/trust oriented keyrings? I imagine we would likely need some mechanism to link a key from the existing source/trust keyrings, e.g. ".machine", to a task specific keyring, e.g. ".modulesigning", but I can't imagine that would be too difficult. Regardless, back to Clavis ... reading quickly through the cover letter again, I do somewhat wonder if this isn't better integrated into the keyring proper; have you talked to both David and Jarkko about this? Were they supportive of the idea, but simply felt it was better as an LSM? I see Jarkko has reviewed and commented on a number of the patches, so I'll take that as an implicit acceptance of the concept, but have you heard anything from David? -- paul-moore.com
