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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhSoPK7zMQjUNiHG23Je-iSmxOSdRFvp1ikqCeCxkS9zWw@mail.gmail.com>
Date: Sat, 5 Oct 2024 12:21:31 -0400
From: Paul Moore <paul@...l-moore.com>
To: "Dr. Greg" <greg@...ellic.com>
Cc: John Johansen <john.johansen@...onical.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Jonathan Corbet <corbet@....net>, 
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, LKML <linux-kernel@...r.kernel.org>, 
	linux-security-module@...r.kernel.org
Subject: Re: [GIT PULL] tomoyo update for v6.12

On Fri, Oct 4, 2024 at 10:34 PM Dr. Greg <greg@...ellic.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@...ellic.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@...l-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.

-- 
paul-moore.com