[GIT PULL] tomoyo update for v6.12

[Paul Moore]

On Mon, Oct 7, 2024 at 7:22 AM Dr. Greg <greg at enjellic.com> wrote:
> On Sat, Oct 05, 2024 at 12:21:31PM -0400, Paul Moore wrote:
> > On Fri, Oct 4, 2024 at 10:34???PM Dr. Greg <greg at enjellic.com> 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 at enjellic.com> 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 at paul-moore.com> 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@mail.gmail.com
> > >
> > > 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.
>
> The document is an embodiment of a political process, let me take a
> swing at defining what it is:

It's a shame that such a pedantic response failed to take note that
the first sentence in my original comment on the doc never claimed
there wasn't a political aspect, only that to consider it entirely, or
"purely", political is not accurate in my opinion.

Of course you're welcome to believe whatever you like about the
document, its intent, etc. as that is no business of mine outside a
mischaracterization of my own comments.  I think that's about all I've
got to say on that issue right now.

> So the path forward to address this problem, the best that we can hope
> for, is to develop an architecture that minimizes the need for
> consensus on how to implement a security architecture.
>
> Tetsuo has placed one idea on the table, we will see where that goes
> and how long it ultimately takes.

I have yet to see any patches over the past year or two changing how
LSMs are registered with the LSM framework from Tetsuo that are
acceptable upstream.

-- 
paul-moore.com