ANN: new LSM guidelines

Casey Schaufler casey at schaufler-ca.com
Fri Sep 8 20:53:40 UTC 2023


On 9/8/2023 10:29 AM, Paul Moore wrote:
> 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."

Better. Thank you.



More information about the Linux-security-module-archive mailing list