On Thu, Aug 3, 2023 at 5:44 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > 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@xxxxxxxxxxx> 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. Nice. I made some slight changes while adding it to the doc, take a look and let me know what you think. > > > > * 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. Okay, I reworked that requirement slightly, please give it a look -- paul-moore.com
