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

[John Johansen <john.johansen@canonical.com>]

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

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

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

> 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].
> 
> The following are links to the four submissions.  We believe an
> unbiased observer would conclude that they provide ample evidence of
> very little interest in reviewing submissions for enhancements to the
> Linux security eco-system, outside of perhaps certain constituencies:
> 
> V1:
> https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/#t
> 
> V2:
> https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@enjellic.com/T/#t
> 
> V3:
> https://lore.kernel.org/linux-security-module/20240401105015.27614-1-greg@enjellic.com/T/#t
> 
> V4:
> https://lore.kernel.org/linux-security-module/20240826103728.3378-1-greg@enjellic.com/T/#t
> 
> As of the V4 release, we have added support for an approach that may
> positively impact Tetsuo's concerns.  We do that without touching any
> infrastructure outside of our proposed LSM.
> 
> We can speak, at great length, as to why we feel that Linux would
> benefit from structural improvements to its security infrastructure.
> We will refrain from doing so in this thread, given your stated
> sentiments on these types of discussions.
> 
> However, your mantra, recently expressed on security infrastucture
> issues, has always been:
> 
> "Code talks, bullshit walks."
> 
> For all of this to work, and the Linux community to remain healthy,
> the code needs to be listened to and that is not effectively happening
> in the security arena.
> 
> I started my involvement with Linux in late 1991.  All of what I see
> is giving me a great deal of pause about the health of our community
> moving forward and the potential negative impact these issues have on
> the opportunity for security innovation to emerge
> 
>>                    Linus
> 
> Have a good remainder of the week.
> 
> Apologies in advance for extending conversations you find tiresome.
> 
> As always,
> Dr. Greg
> 
> The Quixote Project - Flailing at the Travails of Cybersecurity
>                https://github.com/Quixote-Project
> 
> 
> [1]: A thank you to Casey Schaufler, despite our lively disagreement
> about some issues, who has offered specific review comments and
> dialogue about security modeling.  To Greg Kroah Hartman for
> recommending the most important change we have implemented with
> respect to JSON encoding of security events and a handful of other
> individuals who have provided helpful procedural and technical point
> suggestions.
>