Re: ANN: new LSM guidelines

[Paul Moore <paul@paul-moore.com>]

On Thu, Jul 6, 2023 at 8:32 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> 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.

That's a good point, likely worth mentioning.  We're currently being
bit by that with SafeSetID, so the implicit understanding may need to
be made a bit more explicit.

> 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.

I hadn't thought of adding a section on adding new LSM hooks, but that
seems like a good idea too.  Thanks.

-- 
paul-moore.com