On Thu, Feb 27, 2025 at 05:22:22PM -0500, Paul Moore wrote: > On Thu, Feb 27, 2025 at 3:41 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote: > > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > > > > > > > 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? > > > > > > > > I realize I should probably expand on my thinking a bit, especially > > > > since my comment a while regarding LSMs dedicated to enforcing access > > > > control on keys is what was given as a reason for making Clavis a LSM. > > > > > > > > I still stand by my comment from over a year ago that I see no reason > > > > why we couldn't support a LSM that enforces access controls on > > > > keyrings/keys. What gives me pause with the Clavis LSM is that so > > > > much of Clavis is resident in the keyrings themselves, e.g. Clavis > > > > policy ACLs and authorization keys, that it really feels like it > > > > should be part of the keys subsystem and not a LSM. Yes, existing > > > > LSMs do have LSM specific data that resides outside of the LSM and in > > > > an object's subsystem, but that is usually limited to security > > > > identifiers and similar things, not the LSM's security policy. > > > > Hi Jarkko, David, > > > > Both Paul's and my main concerns with this patch set is storing policy in the > > keyring. We would appreciate your chiming in here about storing key policy in > > the keyring itself. > > 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. I get the theoretical concern but cannot see anything obvious in the patch set that would nail into practical concerns. > > -- > paul-moore.com BR, Jarkko
