Re: [GIT PULL] tomoyo update for v6.12

[Paul Moore]

On Fri, Oct 4, 2024 at 10:34 PM Dr. Greg <greg@xxxxxxxxxxxx> wrote:
> On Fri, Oct 04, 2024 at 02:58:57PM -0400, Paul Moore wrote:
> > On Fri, Oct 4, 2024 at 2:40???PM Dr. Greg <greg@xxxxxxxxxxxx> wrote:
> > > On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:
> > > > On 10/2/24 03:38, Dr. Greg wrote:
> > > > >On Tue, Oct 01, 2024 at 09:36:16AM -0700, Linus Torvalds wrote:
> > > > >>On Tue, 1 Oct 2024 at 07:00, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> >
> > ...
> >
> > > The third problem to be addressed, and you acknowledge it above, is
> > > that there needs to be a flexible pathway for security innovation on
> > > Linux that doesn't require broad based consensus and yet doesn't
> > > imperil the kernel.
>
> > The new LSM guidelines are documented at the URL below (and
> > available in the README.md file of any cloned LSM tree), the
> > document is also linked from the MAINTAINERS file:
> >
> > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-guidelines
> >
> > The guidelines were developed last summer on the LSM mailing list
> > with input and edits from a number of LSM developers.
> >
> > https://lore.kernel.org/linux-security-module/CAHC9VhRsxARUsFcJC-5zp9pX8LWbKQLE4vW+S6n-PMG5XJZtDA@xxxxxxxxxxxxxx
>
> We are intimately familiar with those documents.
>
> Our reference was to the need for a technical solution, not political
> medicaments.

Seeing that document as a purely political solution to the challenge
of gaining acceptance for a new LSM is a telling perspective, and not
an accurate one as far as I'm concerned.  The document spells out a
number of things that new LSMs should strive to satisfy if they want
to be included in the upstream Linux kernel; it's intended as guidance
both for the development of new LSMs as well as their review.

If those guidelines are too restrictive or otherwise stifling, you are
always welcome to suggest changes on the LSM list; that is how the doc
was established and that is how we'll keep it current and resonable.

However, if you find yourself objecting to the guidelines simply
because they are trying your patience, or you find that the technical
reviews driven by those guidelines are incorrect, but are unable to
properly respond in a way that satisfies the reviewer, then the
upstream Linux kernel may not be the best place for your LSM.

-- 
paul-moore.com