[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 at enjellic.com> 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 at paul-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.
>> 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.