ANN: new LSM guidelines
Paul Moore
paul at paul-moore.com
Fri Sep 8 17:29:18 UTC 2023
On Fri, Sep 8, 2023 at 12:03 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 9/7/2023 3:12 PM, Paul Moore wrote:
> > On Thu, Aug 3, 2023 at 5:38 PM Paul Moore <paul at paul-moore.com> wrote:
> >> On Wed, Aug 2, 2023 at 6:00 PM Paul Moore <paul at paul-moore.com> wrote:
> >>> On Tue, Aug 1, 2023 at 6:47 PM Paul Moore <paul at paul-moore.com> wrote:
> >>>> I've updated the README.md doc based on the feedback, and copied the
> >>>> two new sections below for easier review. If anyone has any
> >>>> additional feedback or concerns, please let me know.
> >>> Another update based on feedback received (thanks everyone!). Just as
> >>> before, I welcome any comments or feedback you are able to share.
> >> MOAR UPDATES!
> >>
> >> ## New LSM Hook Guidelines
> > ..
> >
> >> ## New LSM Guidelines
> >>
> >> Historically we have had few requirements around new LSM additions, with
> >> Arjan van de Ven being the first to describe a basic protocol for accepting new
> >> LSMs into the Linux kernel[^1]. In an attempt to document Arjan's basic ideas
> >> and update them for modern Linux kernel development, here are a list of
> >> requirements for new LSM submissions:
> >>
> >> * 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.
> > Based on some off-list discussions, I've added some text to the end of
> > the paragraph above to allow for a reasonable plan of succession in
> > cases where the original LSM authors are not able to commit to long
> > term support. Just as before, comments are always welcome :)
> >
> > Here is the new paragraph:
> >
> > "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 authors' employment with the original company, or the
> > company's backing of the LSM. If the authors are not able to commit to
> > supporting the LSM for an extended period of time, a reasonable succession plan
> > must be submitted along with the LSM."
>
> This makes it sound like LSMs are always developed for corporate use.
I'll agree that I could probably phrase the paragraph above s little
better, but I disagree with the assertion that the paragraph implies
"LSMs are always developed for corporate use".
How about the following:
"The new LSM's author(s) must commit to maintain and support the new LSM for
an extended period of time; this applies both to authors that are employed to
develop and maintain a LSM as well as those that develop and maintain a LSM on
their own time. If the authors are currently supporting a LSM as part of their
employment, there is an expectation upstream that support will continue beyond
the authors' tenure at their current company. In either case, if the authors
are unable to commit to supporting the LSM for an extended period of time, a
reasonable succession plan must be submitted along with the LSM."
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list