Hi, On 8/2/23 14:56, Paul Moore wrote: > On Wed, Aug 2, 2023 at 2:38 PM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: >> >> I like this guideline. I guess this is your goal and I think it should >> be part of Documentation/security/lsm.rst (and move the introduction >> part of lsm-development.rst into lsm.rst) and get a few SoB. > > Thanks for the review and comments. Responses below, but I'll post an > updated guidance doc in just a bit incorporating your feedback as well > as those of a few others who sent me comments off-list. > > As far as moving this guidance into Documentation/security, yes, that > is the ultimate goal. In fact I have a todo item to go through all of > Documentation/security and give it a good cleaning/review/edit, > although please don't expect that anytime soon :/ > >> On Tue, Aug 01, 2023 at 06:47:12PM -0400, Paul Moore wrote: >>> On Fri, Jul 7, 2023 at 6:02 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: >>>> On Thu, Jul 6, 2023 at 8:32 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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 ... >>> >>> 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. >>> >>> ## New LSM Hook Guidelines >>> >>> While LSM hooks are generally considered outside of the Linux Kernel's stable >> >> Why "generally"? > > Good point, I'll remove that. > >>> API promise, due to the nature of the LSM hooks we try to minimize changes to >>> the hooks. With that in mind, we have the following requirements for new LSM >>> hooks: >>> >>> * Hooks should be designed to be LSM agnostic. While it is possible that only >>> one LSM might implement the hook at the time of submission, the hook's behavior >>> should be generic enough that other LSMs could provide a meaningful >>> implementation. >> >> We should also avoid falling in the other extreme which is to add >> different argument just-in-case. For instance, there is no need to add a >> "flags" argument to a kernel API if there is no flag for now, especially >> if there are only a few users of this hook. >> >> I would say that we want generic-as-possible hooks (e.g. well >> positioned) but not with useless arguments. > > Agreed, although I think that's hard to properly describe that in a > sentence or two. It's going to be impossible to capture every > requirement in this doc (I added a new paragraph explaining this in > the latest revision), so I think we can just leave this as-is for now. > > If it does become a problem we can work a bit harder on describing > what makes a "good" LSM hook. > >>> * 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? > >>> ## New LSM Guidelines >>> >>> Historically we have had few requirements around new LSM additions, with >>> Arjan van de Ven being the first to describe a basic protocol for accepting new >>> LSMs into the Linux Kernel. In an attempt to document Arjan's basic ideas and >>> update them for modern Linux Kernel development, here are a list of >>> requirements for new LSM submissions: >> >> If we go for a kernel documentation patch, it might be better to put >> most of this historic paragraph into the patch description. > > Agree. > > I was looking for the original comments from Arjan but couldn't find > them in an archive anywhere, if anyone has a pointer it would be great > to share that. Are you referring to either of these? https://lore.kernel.org/all/20071026141358.38342c0f@xxxxxxxxxxxxxxxxxxxxx/ https://lore.kernel.org/lkml/20071024191933.53094b81@xxxxxxxxxxxxxxxxxxxxx/ -- ~Randy
