Hi,

On 8/2/23 14:56, Paul Moore wrote:

On Wed, Aug 2, 2023 at 2:38 PM Mickaël Salaün [off-list ref] wrote:

quoted

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 :/

quoted

On Tue, Aug 01, 2023 at 06:47:12PM -0400, Paul Moore wrote:

quoted

On Fri, Jul 7, 2023 at 6:02 PM Paul Moore [off-list ref] wrote:

quoted

On Thu, Jul 6, 2023 at 8:32 PM Casey Schaufler [off-list ref] wrote:

quoted

On 7/6/2023 1:42 PM, Paul Moore wrote:

quoted

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.

quoted

quoted

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.

quoted

quoted

* 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?

quoted

quoted

## 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@laptopd505.fenrus.org/ (local)

https://lore.kernel.org/lkml/20071024191933.53094b81@laptopd505.fenrus.org/ (local)

-- 
~Randy