ANN: new LSM guidelines

[Randy Dunlap]

Hi,

On 8/2/23 14:56, Paul Moore wrote:
> On Wed, Aug 2, 2023 at 2:38 PM Mickaël Salaün <mic at digikod.net> 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 at paul-moore.com> wrote:
>>>> On Thu, Jul 6, 2023 at 8:32 PM Casey Schaufler <casey at schaufler-ca.com> 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@laptopd505.fenrus.org/

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

-- 
~Randy