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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 4, 2025 at 5:25 PM Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote:
> On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote:
> > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote:
> > > > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
> > > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > >>>
> > > >>> 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.
> > >
> > > The intent is not to limit ourselves to the source of the key.  The main
> > > point of Clavis is to allow the end-user to determine what kernel keys
> > > they want to trust and for what purpose, irrespective of the originating
> > > source (.builtin_trusted, .secondary, .machine, or .platform). If we could
> > > go back in time, individual keyrings could be created that are oriented
> > > toward usage.   The idea for introducing Clavis is to bridge what we
> > > have today with kernel keys and allow them to be usage based.
> >
> > While it is unlikely that the current well known keyrings could be
> > removed, I see no reason why new usage oriented keyrings could not be
> > introduced.  We've seen far more significant shifts in the kernel over
> > the years.
>
> Could we implement such change in a way that these new imaginary
> (at this point) usage oriented keyrings would be used to create
> the "legacy" keyrings?

I think it would be easier for them to coexist so that one could have
an easier migration.  It's possible that even once everything was
migrated to the new usage oriented keyrings it would still make sense
to keep the existing keyrings in place and always link keys from there
to the newer usage keyrings.

-- 
paul-moore.com





[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux