ANN: new LSM guidelines

[Paul Moore]

On Thu, Aug 3, 2023 at 5:44 AM Mickaël Salaün <mic at digikod.net> wrote:
> On Wed, Aug 02, 2023 at 05:56:42PM -0400, Paul Moore wrote:
> > On Wed, Aug 2, 2023 at 2:38 PM Mickaël Salaün <mic at digikod.net> wrote:
>
> [...]
>
> > > > * There must be at least one LSM implementation of the hook included in the
> > > > submission to act as a reference for additional LSM implementations.  The
> > > > reference implementation must be for one of the upstream, in-kernel LSMs; while
> > > > the BPF LSM is an upstream LSM, it's nature precludes it from being eligible as
> > > > one of the in-kernel LSMs.
> > >
> > > To avoid misunderstanding, I think it would be better and more generic
> > > to focus on the out-of-tree nature of hook implementations.  We might
> > > also want to give some pointers for the reason(s) why out-of-tree LSMs
> > > use cases are not supported.
> >
> > I'm open to new language here if you have some particular wording in mind?
>
> What about this?
>
> * Every hook must demonstrate its usefulness and be actually used by
>   in-kernel code.  This is required to understand the purpose of the LSM
>   hooks, their expected semantic, and to be able to guarantee security
>   properties throughout kernel code changes (e.g., thanks to regression
>   testing).  This means that out-of-tree kernel code and pass-through
>   implementations (e.g., BPF LSM) are not eligible for such reference
>   implementations.

Nice.  I made some slight changes while adding it to the doc, take a
look and let me know what you think.

> > > > * The new LSM's author(s) must commit to maintain and support the new LSM for
> > > > an extended period of time.  While the authors may be currently employed to
> > > > develop and support the LSM, there is an expectation upstream that support will
> > > > continue beyond the author's employment with the original company, or the
> > > > company's backing of the LSM.
> > > >
> > > > * New LSMs must include documentation providing a clear explanation of the
> > > > LSM's requirements, goals, and expected uses.  The documentation does not need
> > > > to rise to the level of a formal security model, but it must be considered
> > > > "reasonable" by the LSM community as a whole.
> > >
> > > I guess defining the threat model would be a good first step (and we
> > > should probably add this kind of description for current LSMs as well).
> >
> > I believe that should be captured in the "requirements, goals, and
> > expected uses" portion of the requirement above, but if you believe it
> > should be more explicit let me know.
>
> I think explicitly using "threat model" in this paragraph would be a
> good idea.

Okay, I reworked that requirement slightly, please give it a look

-- 
paul-moore.com