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

[John Johansen]

On 10/2/24 07:35, Paul Moore wrote:
> On Wed, Oct 2, 2024 at 6:38 AM Dr. Greg <greg@xxxxxxxxxxxx> 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:
> > > > 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.
> > 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.
>
> I've believe the LSM developer community is interesting in that it is
> much smaller than many other kernel subsystems, despite the
> substantial technical scope when one considers the LSM's reach within
> the kernel.  This brings about a number of challenges, the largest
> being that reviewing ideas, documents, and code changes takes time.
> Everyone always wants their personal patchset to land "right now!",
> but it's important that the changes are given the proper review and
> testing.  You don't have to look any further than the recent static
> call changes to see a perfect example of how overly aggressive
> attitudes toward merging would have resulted in a number of real world
> failures.  I agree that a quicker pace would be nice, but I'm not
> willing to trade off reliability or correctness so people's favorite
> feature can land in Linus' tree a bit quicker.
>
> Independent of everything above, it is important to note that the pace
> of changes in the LSM framework over the past two years has increased
> significantly.  Even ignoring some of the administrative improvements,
> e.g. process documentation, since 2022 the LSM community has been
> merging code at a pace much higher than we've seen during the entirety
> of the "git age":
>
> [NOTE: using 'security/security.c' to be representative of LSM
> framework specific changes seems reasonable for a quick metric]
>
> # previous two years (reference)
> % git log --after="2022" --before="2024" \
>    --oneline security/security.c | wc -l
> 141
>
> % git log --after="2020" --before="2022" ...
> 50
> % git log --after="2018" --before="2020" ...
> 82
> % git log --after="2016" --before="2018" ...
> 43
> % git log --after="2014" --before="2016" ...
> 47
> % git log --after="2012" --before="2014" ...
> 25
> % git log --after="2010" --before="2012" ...
> 62
> % git log --after="2008" --before="2010" ...
> 56
> % git log --after="2006" --before="2008" ...
> 36
> % git log --after="2004" --before="2006" ...
> 4
> % git log --after="2002" --before="2004" ...
> 0
>
> > We have made multiple submissions of technology, that can at least
> > positively impact Tetsuo's concerns, and in the process perhaps
> > improve the opportunity for security innovation in Linux.  After 20
> > months of doing so we have yet to receive anything that would resemble
> > substantive technical review [1].
>
> I disagree.  I've personally reviewed two of your LSM revisions,
> providing feedback on both.  Unfortunately both times I've not made it
> past the documentation as there have been rather significant issues
> which I didn't believe were properly addressed from one revision to
> the next.  From what I've seen on the mailing list, others have
> identified similarly serious concerns which in my opinion have not
> received adequate responses.
>
> The TSEM LSM is still queued for review, but based on prior reviews it
> currently sits at a lower priority.  I realize this is frustrating,
> but I have to prioritize work based on impact and perceived quality.
Bandwidth is a very real issue. TSEM is also on my to review list, but
finding making the time to make it through the full set has so far
been impossible.

Heck I am weeks behind on the apparmor list, and I have apparmor patches
to send that I haven't been able to get time to do.