ANN: new LSM guidelines

[Casey Schaufler]

On 7/6/2023 1:42 PM, Paul Moore wrote:
> Hello all,
>
> With some renewed interest in submitting new LSMs including in the
> upstream Linux Kernel I thought it might be a good idea to document
> some of our longstanding guidelines around submitting new LSMs.  I'm
> posting this mostly as a FYI for those who are working on new LSM
> submissions, but also to solicit feedback from everyone on the list
> regarding what we should ask of new LSMs.  If you think I'm missing
> something important, or believe I've added an unfair requirement,
> please let me know.
>
> I've added the guidelines to the README.md at the top of the LSM tree,
> but to make life easier for those reviewing the guidelines I'm
> copy-n-pasting them below:
>
> * 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.
>
> * Any user visible interfaces provided by the LSM must be well
> documented. It is important to remember the user visible APIs are
> considered to be "forever APIs" by the Linux Kernel community; do not
> add an API that cannot be supported for the next 20+ years.
>
> * Any userspace tools or patches created in support of the LSM must be
> publicly available, with a public git repository preferable over a
> tarball snapshot.
>
> * The LSM implementation must follow general Linux Kernel coding
> practices, faithfully implement the security model and APIs described
> in the documentation, and be free of any known defects at the time of
> submission.

Some commitment to maintaining the LSM for a reasonable time must be
provided. Although this should probably be implicit in the use cases
and goals, changes in product direction or employment status can leave
an LSM orphaned before its time.

New LSM hooks introduced need to be generically usable. Use of LSM
specific data should be avoided. The hook should include data at a
granularity that can accommodate the existing LSMs as well as the
new one. The data granularity must be appropriate for the sub-system
from which it is called.

>
> The entire README.md file, including the guidelines above, can also be
> viewed in your browser at the link below:
>
> * https://github.com/LinuxSecurityModule/kernel/blob/main/README.md
>