ANN: new LSM guidelines

[Mickaël Salaün]

On Wed, Aug 02, 2023 at 05:56:42PM -0400, Paul Moore wrote:
> On Wed, Aug 2, 2023 at 2:38 PM Mickaël Salaün <mic at digikod.net> wrote:

[...]

> > > * There must be at least one LSM implementation of the hook included in the
> > > submission to act as a reference for additional LSM implementations.  The
> > > reference implementation must be for one of the upstream, in-kernel LSMs; while
> > > the BPF LSM is an upstream LSM, it's nature precludes it from being eligible as
> > > one of the in-kernel LSMs.
> >
> > To avoid misunderstanding, I think it would be better and more generic
> > to focus on the out-of-tree nature of hook implementations.  We might
> > also want to give some pointers for the reason(s) why out-of-tree LSMs
> > use cases are not supported.
> 
> I'm open to new language here if you have some particular wording in mind?

What about this?

* Every hook must demonstrate its usefulness and be actually used by
  in-kernel code.  This is required to understand the purpose of the LSM
  hooks, their expected semantic, and to be able to guarantee security
  properties throughout kernel code changes (e.g., thanks to regression
  testing).  This means that out-of-tree kernel code and pass-through
  implementations (e.g., BPF LSM) are not eligible for such reference
  implementations.

[...]

> > > * 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.
> > >
> > > * 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.
> >
> > I guess defining the threat model would be a good first step (and we
> > should probably add this kind of description for current LSMs as well).
> 
> I believe that should be captured in the "requirements, goals, and
> expected uses" portion of the requirement above, but if you believe it
> should be more explicit let me know.

I think explicitly using "threat model" in this paragraph would be a
good idea.

> 
> > > * 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.
> >
> > I would also add tests! For new kernel developments, especially those
> > focused on security, the interfaces should be well tested, part of
> > kselftests, and run at least for each kernel release (if possible with
> > the KernelCI infrastructure).  A good test coverage should be a minimal
> > requirement, even if this is not enough.  Additionally, syzkaller should
> > be able to efficiently fuzz these interfaces, which may require some
> > tuning.
> 
> I added a test suite requirement to the latest revision.  I didn't
> explicitly require kselftests, as not all current LSMs with tests make
> use of kselftest, but I do think requiring some type of test suite is
> important.

Ok, see my comments in the updated doc.