ANN: new LSM guidelines

[Paul Moore]

On Fri, Sep 8, 2023 at 8:46 PM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
> On 2023/08/03 7:00, Paul Moore wrote:
> > * The new LSM must be sufficiently unique to justify the additional work
> > involved in reviewing, maintaining, and supporting the LSM.  It is reasonable
> > for there to be a level of overlap between LSMs, but either the security model
> > or the admin/user experience must be significantly unique.
>
> s/work/burden/ ?

Possibly, although I think I prefer "work" here since it has a more
positive connotation than "burden".

> > * Any userspace tools or patches created in support of the LSM must be publicly
> > available, with a public git repository preferable over a tarball snapshot.
>
> What is the definition of "publicly" here? Everyone can download related resources
> including the source code etc. anonymously (e.g. without asking for creating user
> account and/or buying subscriptions ) ?

I agree with Serge that you bring up a very good point, and I think
the requirement of being able to download and use the tools without
requiring a account, subscription, etc. is a good one.

I've replaced that guideline with the following:

"If new userspace tools, or patches to existing tools, are necessary to
configure, operate, or otherwise manage the LSM, these tools or patches must
be publicly available without download restrictions requiring accounts,
subscriptions, etc.  Maintaining these tools or patches in a public git
repository is preferable over tarball snapshots."

I made a similar edit to the test suite guidelines:

"New LSMs must be accompanied by a test suite to verify basic functionality
and help identify regressions.  The test suite must be publicly available
without download restrictions requiring accounts, subscriptions, etc.  Test
coverage does not need to reach a specific percentage, but core functionality
and any user interfaces should be well covered by the test suite.  Maintaining
the test suite in a public git repository is preferable over tarball snapshots.
Integrating the test suite with existing automated Linux kernel testing
services is encouraged."

What do you think?

> If one of userspace tools designed for the new LSM depends on the LSM ID, when can
> the author of the new LSM obtain the stable LSM ID for that LSM ?

A permanent LSM ID is assigned to LSMs when they are merged into the
upstream LSM tree.  This is no different than any other kernel defined
macro constant, enum, magic number, etc. that is shared between kernel
and userspace and is considered part of the kernel's API.

LSM developers creating userspace tooling that makes use of the LSM ID
numbers should use the macro name and not the number, this should
allow the tooling to support the permanent LSM ID with a simple
recompile.

I understand you are opposed to the numeric LSM ID as part of the
kernel's API, but I believe this is both the correct way forward, and
consistent with other kernel APIs.  It is your right to disagree, but
I have yet to see a reason to revisit this decision and respectfully
request that you accept this and refrain from revisiting this argument
unless you have new information which would warrant a new discussion.

-- 
paul-moore.com