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

[Paul Moore]

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.

-- 
paul-moore.com