[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <033eb4d9-482b-4b70-a251-dc8bcc738f40@canonical.com>
Date: Wed, 2 Oct 2024 19:27:47 -0700
From: John Johansen <john.johansen@...onical.com>
To: "Dr. Greg" <greg@...ellic.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: 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 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
> 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.
>
Powered by blists - more mailing lists