ANN: new LSM guidelines

Paul Moore paul at paul-moore.com
Thu Aug 3 21:24:15 UTC 2023


On Thu, Aug 3, 2023 at 5:44 AM Mickaël Salaün <mic at digikod.net> wrote:
>
> On Wed, Aug 02, 2023 at 06:00:22PM -0400, Paul Moore 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.
> >
> > ## New LSM Hook Guidelines
> >
> > While LSM hooks are considered outside of the Linux Kernel's stable API
>
> s/Kernel/kernel/g

Done for the entire doc.

> > * New LSMs must be accompanied by a test suite to verify basic functionality
> > and help identify regressions.  Test coverage does not need to reach a specific
> > percentage, but core functionality and any user interfaces should be well
> > covered by the test suite.  Integration with existing automated Linux Kernel
> > testing services is encouraged.
>
> I'd suggest to require tests to be publicly available and easy (or not
> too difficult) to run for the sake of sanity of other kernel developers
> that might need to quickly fix (critical) bugs even without the help of
> the maintainer (who might be unavailable for various reasons).

Good point.  We mention a public repository for associated userspace
tools/patches, we should do the same for the tests.  While I also
agree that the tests should be easy to setup and run, I'm not sure I
want to put that as a requirement simply because it is so hard to
properly quantify.

> I guess
> you could argue that decent kernel code needs a reasonable bus factor
> protection, but making tests available and easy to use is a quality
> guarantee.

At one point I debated adding a requirement about having a "community"
behind new LSM submissions, but I worry that would introduce a
chicken/egg problem.  In theory, if a LSM is properly documented, has
meaningful tests, and is reasonably coded, any interested party could
pick it up if the original author/maintainer ceased maintaining the
code.

-- 
paul-moore.com



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