Message-ID: <20241004184019.GA16388@wind.enjellic.com>
Date: Fri, 4 Oct 2024 13:40:19 -0500
From: "Dr. Greg" <greg@...ellic.com>
To: John Johansen <john.johansen@...onical.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
        Paul Moore <paul@...l-moore.com>, 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 Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:

Hi, I hope the week has gone well for everyone.

> On 10/2/24 03:38, Dr. Greg wrote:
> >On Tue, Oct 01, 2024 at 09:36:16AM -0700, Linus Torvalds wrote:
> >
> >Good morning Linus, I hope the week is going well for you.
> >
> >Some reflections, for the record, on this issue.
> >
> >>On Tue, 1 Oct 2024 at 07:00, Paul Moore <paul@...l-moore.com> wrote:
> >>>
> >>>Linus, it's unclear if you're still following this thread after the
> >>>pull, but can you provide a little insight on your thoughts here?
> >
> >>I absolutely hate the whole "security people keep arguing", and I
> >>cannot personally find it in myself to care about tomoyo.  I don't
> >>even know where it is used - certainly not in Fedora, which is the
> >>only distro I can check quickly.
> >>
> >>If the consensus is that we should revert, I'll happily revert. This
> >>was all inside of the tomoyo subdirectory, so I didn't see it as
> >>some kind of sidestepping, and treated the pull request as a regular
> >>"another odd security subsystem update".
> >
> >I see that Paul Moore has further responded with commentary about the
> >'LSM community' responding to this issue.  I wanted, on behalf of our
> >project and in support of Tetsuo's concerns, to register directly with
> >you a sense of jaded skepticism about the notion of a community
> >response.
> >
> >Fixing Tetsuo's issue, at least to the extent it can be fixed,
> >requires technical improvements in the Linux security architecture.

> yes and that is correct place to do it. Doing it within a single LSM
> is very much the wrong approach

I don't disagree and have publically stated that a number of times
over the last 10 months or so that this issue has been raging,
including in e-mail to Tetsuo himself.

Our opinion or ACK doesn't matter much in the grand scheme of things,
but Paul can feel free to take his black sharpie pen and place a mark
in the column that indicates that it is in everyone's interest to have
a standard framework for security event dispatch, on our behalf.

That being said, if we are actually serious about responding properly
to this event/crisis, we need to step back and have an intellectually
honest engineering discussing surrounding the following question:

Has the threat environment, its significance to society and industry
and the scale and scope of the solutions needed to mount a response to
it, changed since the inception of the LSM 22 years ago?

Colleagues I have in the counseling industry tell me that the first
step in resolving a problem is recognizing that there is a problem.

> >Currently, potential technical improvements in this venue are
> >struggling to receive any kind of acknowledgement or review, to the
> >ultimate detriment of enhancements that Linux should be bringing
> >forward to address, not only this issue, but the security industry
> >writ-large.

> everyone in the LSM community is struggling with available time, and
> yes there are disagreements around how this should be done so it
> moves slow.

With respect to bandwidth there are two problems that need to addressed:

1.) The amount of time and talent it takes for developers to implement
security policies with mandatory enforcement capabilities.

2.) The ability to implement security technology solutions on linux,
based on a standardized infrastructure, in less than 4-5+ year
timeframes.

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.

This latter issue is the most fundamental problem with security on
Linux and something that Linus has publically complained about
multiple times, as we all know.

With TSEM we placed a design on the table, influenced by individuals
with significant experience in the field and its challenges, that was
a legitimate attempt to address these issues, including the problem
that Tetuso has.  Unfortunately it sat on the cutting room floor for
20 months without even a legitimate technical discussion as to its
motivation and design and the fact that it could have provided a
method to derail this current crisis/controversy.

We fully recognize and respect the bandwidth crisis.  If it is as bad
as everyone claims it is, and there is no reason to assume otherwise,
then we need to acknowledge and address this issue as one of the two
roots of our problem, if security innovation on Linux is to remain
even remotely relevant and healthy.

We appreciate your willingness to review TSEM sometime down the road
and will look forward to your thoughts.

Have a good weekend.

As always,
Dr. Greg

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

Powered by blists - more mailing lists