Message-ID: <20241007112158.GA10114@wind.enjellic.com>
Date: Mon, 7 Oct 2024 06:21:58 -0500
From: "Dr. Greg" <greg@...ellic.com>
To: Paul Moore <paul@...l-moore.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 Sat, Oct 05, 2024 at 12:21:31PM -0400, Paul Moore wrote:

Good morning, I hope the week is starting well for everyone.

> 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.

The document is an embodiment of a political process, let me take a
swing at defining what it is:

It is a collaboratively developed instrument for establishing
normative guidelines and practices, among a diverse group of
individuals with varying goals and objectives, who desire to cooperate
to create an environment that supports the resolution of conflicts in
the pursuit of individual objectives while maintaining a common good.

I think we have all been around long enough to understand that Linux
kernel development and distribution is a study in technical politics,
probably more so than ever.

You don't have to take my word for it.  Our Quixote team is fortunate
enough to have as a member, a valued consigliere, who hangs both a J.D
and a Ph.D. off the end of her name.  The latter in political science
whose 600+ page dissertation studied, among other issues, the role of
mediation in a legal system.

She was influenced by a top constitutional scholar, and as we all
know, the US constitution was a document designed to mediate a
political process in the pursuit of the common good.

We could get an opinion from her, if you want to take on her hourly
rates.  I'm pretty confident she would conclude that this is a
political process and the ANN document is an instrument for mediating
that process.

For the record, we have no issues with the document.  It is a bit
light on rights of participants in the process and requirements for
leadership, but that is a subject for another day and perhaps the
kernel community at large.

Interestingly enough, and relevant to these conversations, is that
Tetsuo has consistently called out the 'patent' requirements of the
document as problematic.  Once again, a subject for another
conversation.

Citing the document in response to our suggestion that there needs to
be a flexible pathway for security innovation, that doesn't require
consensus, misses the point we were making.

As the TOMOYO incident points out, requiring the need to have kernel
resident code to implement a security architecture that samples LSM
events is problematic and will probably become more as time goes on.

>From a commercial perspective, the Linux distributors are being forced
into code signing due to security issues.  As this incident has
demonstrated, the effect of that is to limit choice in security
solutions to what the distributions feel they can or want to support.

>From a technical perspective, history has clearly demonstrated that
security engineers have varying and unique ideas on how security
should be implemented, much to the long stated consternation of Linus
himself.  The LSM is a study in the fact that people cannot agree on
how security should be implemented.

The existence of the ANN document doesn't address either of these
issues.

It addresses how to participate in the process of getting a security
implementation into the kernel proper, which this incident has clearly
demonstrated is the problematic requirement.

We will ultimately never 'fix' this problem because it is a political
problem, given that distributions either want to limit choice for
business purposes or are being forced into it by the current threat
environment.

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.

As I've stated before, we saw this coming about four years ago and
TSEM was designed to provide an architecture that minimizes the need
for consensus on how to do security.

We will litigate elsewhere the current state of issues we have
experienced with that.

> paul-moore.com

Have a good week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

Powered by blists - more mailing lists