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

[Jarkko Sakkinen <jarkko@kernel.org>]

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@linux.ibm.com> wrote:
> > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote:
> > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> 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