ANN: new LSM guidelines

Casey Schaufler casey at schaufler-ca.com
Fri Sep 8 16:02:58 UTC 2023


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.
While that is generally true, we should acknowledge that the "sponsor"
of an LSM could be a corporation/government, a foundation or a hobbyist.
A large, comprehensive LSM from a billion dollar corporation in support
of a specific product should require more commitment than a small, targeted
LSM of general interest from joe at schlobotnit.org. I trust that we would
have the wisdom to make such a distinction, but I don't think we want to
scare off developers by making it sound like an LSM is something that only
a corporation can provide a support plan for.



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