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

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

[Paul Moore]

On Sat, Sep 28, 2024 at 9:55 AM Jonathan Corbet <corbet@lwn.net> wrote:
> Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> > The following changes since commit ada1986d07976d60bed5017aa38b7f7cf27883f7:
> >
> >   tomoyo: fallback to realpath if symlink's pathname does not exist (2024-09-25 22:30:59 +0900)
> >
> > are available in the Git repository at:
> >
> >   git://git.code.sf.net/p/tomoyo/tomoyo.git tags/tomoyo-pr-20240927
> >
> > for you to fetch changes up to ada1986d07976d60bed5017aa38b7f7cf27883f7:
> >
> >   tomoyo: fallback to realpath if symlink's pathname does not exist (2024-09-25 22:30:59 +0900)
> > ----------------------------------------------------------------
> > One bugfix patch, one preparation patch, and one conversion patch.
>
> [...]
>
> > I was delivering pure LKM version of TOMOYO (named AKARI) to users who
> > cannot afford rebuilding their distro kernels with TOMOYO enabled. But
> > since the LSM framework was converted to static calls, it became more
> > difficult to deliver AKARI to such users. Therefore, I decided to update
> > TOMOYO so that people can use mostly LKM version of TOMOYO with minimal
> > burden for both distributors and users.
>
> I must confess that this change confuses me a bit.  Loadable LSM modules
> have been out of the picture for a long time, has that changed now?
>
> Even stranger, to me at least, is the backdoor symbol-export mechanism.
> That seems like ... not the way we do things.  Was the need for this so
> urgent that you couldn't try to get those symbols exported properly?

[ASIDE: Thanks for the heads-up Jon, I've also CC'd the LSM list as I
think this pull request is a surprise to all of us.]

I'm confused, or rather surprised to see this patchset/PR, and even
more surprised to see it has landed in Linus' tree.  While I suppose
we don't explicitly state that LSMs should CC their pull-requests to
the LSM list, there is definitely convention and plenty of history
here.  Even Tetsuo has previously CC'd the TOMOYO pull requests to the
LSM list (below).  Considering the history of TOMOYO pull requests,
LSM conventions, and the contents of the pull request, I can't help
but think the omission here was done with deliberate intent.  I'm also
surprised it was posted, and pulled, roughly two days from the end of
the merge window.

https://lore.kernel.org/linux-security-module/?q=%22%5BGIT+PULL%5D%22+f%3Apenguin-kernel%40i-love.sakura.ne.jp

Unfortunately this pull request was sent while I was traveling and not
in a good position to respond, or even properly notice it; as things
are I'm typing this email from the seat of a plane (the first time
I've had network access on a laptop since Thursday morning).  If I had
seen this last week I would have voiced an objection that this pull
request effectively duplicates the LSM framework hooks in TOMOYO (and
likely a few other things, I'm only quickly scanning the patches ...);
I wouldn't have accepted something like this in a new LSM submission
and I can only see this as a bad faith move on the part of Tetsuo.

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
don't want to go down the "security people are insane" discussion
hole, but I'd would like to know where the line is drawn with
accepting changes like this: are you consciously supportive of
individual LSMs sidestepping the LSM framework like this when they are
not able to gain approval from the LSM maintainer and the LSM
community as a whole?

-- 
paul-moore.com

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

[Linus Torvalds]

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

                  Linus

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

[Paul Moore]

On Tue, Oct 1, 2024 at 12:36 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> 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?

...

> If the consensus is that we should revert, I'll happily revert.

Starting tomorrow when I'm reliably back in front of computer I'll
sort this out with the rest of the LSM folks.  Unless something
unexpected comes up in the discussion I'll send you a revert later
this week.

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

Yes, that's fair, I think you would need a deeper understanding of the
LSM framework as well as an understanding of recent discussions on the
list to appreciate all of the details.

-- 
paul-moore.com

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

[Tetsuo Handa]

On 2024/10/02 1:36, Linus Torvalds 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?

Yes, I want to hear what Linus thinks.

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

As far as I am aware, TOMOYO is enabled in Ubuntu, Debian and openSUSE kernels.
CentOS plus (which provides additional functionality over RHEL, but was killed
by CentOS Stream) kernels also enabled TOMOYO. But not yet in Fedora kernels.

> 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 will revert TOMOYO changes if Paul succeeds in getting rid of
CONFIG_MODULES=y support from the upstream kernel. ;-)



On 2024/10/02 3:22, Paul Moore wrote:
> Starting tomorrow when I'm reliably back in front of computer I'll
> sort this out with the rest of the LSM folks.  Unless something
> unexpected comes up in the discussion I'll send you a revert later
> this week.

What I am asking LSM framework is as simple as
https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp .

Now that built-in LSM modules started using __ro_after_init static calls, !built-in
LSM modules can start using !__ro_after_init linked list without affecting built-in
LSM modules. I can't understand why Paul does not like it.

> Yes, that's fair, I think you would need a deeper understanding of the
> LSM framework as well as an understanding of recent discussions on the
> list to appreciate all of the details.

Yes, please. How strange recent discussions about LSM framework is. :-(

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

[Dr. Greg]

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

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.

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

[Paul Moore]

On Tue, Oct 1, 2024 at 11:32 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2024/10/02 3:22, Paul Moore wrote:
> > Starting tomorrow when I'm reliably back in front of computer I'll
> > sort this out with the rest of the LSM folks.  Unless something
> > unexpected comes up in the discussion I'll send you a revert later
> > this week.
>
> What I am asking LSM framework is as simple as
> https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp .

You mention that Linux hasn't supported loadable LSMs since v2.6.23
when SELinux was the only LSM implementation in the upstream Linux
kernel.  In the (almost) 17 years since then we've seen a number of
new LSMs introduced and merged into the upstream kernel, each having a
voice as to how the LSM framework is managed.

> Now that built-in LSM modules started using __ro_after_init static calls, !built-in
> LSM modules can start using !__ro_after_init linked list without affecting built-in
> LSM modules. I can't understand why Paul does not like it.

A *lot* of effort has gone into both hardening and improving the
performance of the LSM framework.  I'm loath to introduce anything
which would take away from those gains, especially if it is only done
to satisfy out-of-tree LSMs, or users who don't agree with their
distro kernel's build-time configuration.

--
paul-moore.com

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

[Paul Moore]

On Wed, Oct 2, 2024 at 6:38 AM Dr. Greg <greg@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@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.

-- 
paul-moore.com

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

[Tetsuo Handa]

On 2024/10/02 23:01, Paul Moore wrote:
>> Now that built-in LSM modules started using __ro_after_init static calls, !built-in
>> LSM modules can start using !__ro_after_init linked list without affecting built-in
>> LSM modules. I can't understand why Paul does not like it.
> 
> A *lot* of effort has gone into both hardening and improving the
> performance of the LSM framework.  I'm loath to introduce anything
> which would take away from those gains, especially if it is only done
> to satisfy out-of-tree LSMs, or users who don't agree with their
> distro kernel's build-time configuration.

Forcing distro users to rebuild distro kernels (with or without modified
kernel configurations) is no longer a viable solution.

Since cryptography (e.g. module signing keys) is getting used inside kernels,
noone except the one who has the private key and has built the original kernel
can reproduce the same behavior/functionality (even without modified kernel
configurations). Also, from package management perspective, users get confused
by being forced to use different package names/versions (when installing kernel
related packages) and breaking package dependency (when installing userspace
packages). You said

  Comparing userspace applications to kernel code isn't a fair
  comparison as a userspace application can generally be added without
  impacting the other applications on the system.

  Anyone is always free to build their own kernel with whatever code
  changes they like, this is the beauty of the kernel source being
  available and licensed as Open Source.  You are free to build a kernel
  with whatever LSM you like included and enabled.  You have been shown
  examples on how to do this in previous threads.

at https://lkml.kernel.org/r/CAHC9VhQq0-D=p9Kicx2UsDrK2NJQDyn9psL-PWojAA+Y17WiFQ@mail.gmail.com .
But due to above-mentioned realities, your assertion no longer stands.
Kernel source itself might be open, but private keys cannot be open.
The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
negative impact on the user side, which cannot be a viable solution).

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

[Tetsuo Handa]

On 2024/10/03 8:09, Tetsuo Handa wrote:
> The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
> negative impact on the user side, which cannot be a viable solution).

For example, some out-of-tree device driver supports RHEL but does not
support CentOS, despite there is effectively no difference between RHEL
kernel and CentOS kernel.

Also, for debuginfo packages, one has to share/distribute debuginfo packages
when vmcore is captured while using a rebuilt vmlinux. (Well, debuginfo
might not be limited for analyzing vmcore...) That makes troubleshooting more
difficult; one who captured vmcore cannot directly contact the original kernel
provider, due to discarding the baseline provided by the original kernel
provider.

What Paul is saying is effectively "Do not use RHEL if you want to use TOMOYO".
Just rebuilding RHEL kernels impacts negatively on the user side. Who can
force users to rebuild RHEL kernels, due to the burden caused by giving up
utilizing existing eco-system? That cannot be a viable solution.

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

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

[John Johansen]

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

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

[John Johansen]

On 10/1/24 11:22, Paul Moore wrote:
> On Tue, Oct 1, 2024 at 12:36 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> 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?
> 
> ...
> 
>> If the consensus is that we should revert, I'll happily revert.
> 
> Starting tomorrow when I'm reliably back in front of computer I'll
> sort this out with the rest of the LSM folks.  Unless something
> unexpected comes up in the discussion I'll send you a revert later
> this week.
> 
I agree that this is the wrong approach and will add that it is
egregious enough that Ubuntu is going to have to disable Tomoyo as
it effectively allows by-passing signed module loads.

you can add my
Acked-by: John Johansen <john.johansen@canonical.com>

>> 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".
> 
> Yes, that's fair, I think you would need a deeper understanding of the
> LSM framework as well as an understanding of recent discussions on the
> list to appreciate all of the details.
> 

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

[John Johansen]

On 10/2/24 16:09, Tetsuo Handa wrote:
> On 2024/10/02 23:01, Paul Moore wrote:
>>> Now that built-in LSM modules started using __ro_after_init static calls, !built-in
>>> LSM modules can start using !__ro_after_init linked list without affecting built-in
>>> LSM modules. I can't understand why Paul does not like it.
>>
>> A *lot* of effort has gone into both hardening and improving the
>> performance of the LSM framework.  I'm loath to introduce anything
>> which would take away from those gains, especially if it is only done
>> to satisfy out-of-tree LSMs, or users who don't agree with their
>> distro kernel's build-time configuration.
> 
> Forcing distro users to rebuild distro kernels (with or without modified
> kernel configurations) is no longer a viable solution.
> 
and you think this fixes that? All this is going to do is force distros to
disable Tomoyo to be able to continue to support their security stance.

> Since cryptography (e.g. module signing keys) is getting used inside kernels,
> noone except the one who has the private key and has built the original kernel
> can reproduce the same behavior/functionality (even without modified kernel
> configurations). Also, from package management perspective, users get confused
> by being forced to use different package names/versions (when installing kernel
> related packages) and breaking package dependency (when installing userspace
> packages). You said
> 
>    Comparing userspace applications to kernel code isn't a fair
>    comparison as a userspace application can generally be added without
>    impacting the other applications on the system.
> 
>    Anyone is always free to build their own kernel with whatever code
>    changes they like, this is the beauty of the kernel source being
>    available and licensed as Open Source.  You are free to build a kernel
>    with whatever LSM you like included and enabled.  You have been shown
>    examples on how to do this in previous threads.
> 
> at https://lkml.kernel.org/r/CAHC9VhQq0-D=p9Kicx2UsDrK2NJQDyn9psL-PWojAA+Y17WiFQ@mail.gmail.com .
> But due to above-mentioned realities, your assertion no longer stands.
> Kernel source itself might be open, but private keys cannot be open.
> The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
> negative impact on the user side, which cannot be a viable solution).
> 
> 
Yes, and this is an intentional choice on the base of the distro about
what they support and what is required to meet contractual obligations.

Users are still free to build their own kernels they just don't get
support or certification when using them. Stopping the load of out of
tree modules that aren't signed is in general good security policy.

Let me be explicitly clear. If Tomoyo is by-passing module signing, and
exporting the LSM interface to loadable modules Ubuntu will be forced
to disable Tomoyo.

This change is not going to get you closer to what you want. It is
going to force the distros that currently build in Tomoyo to disable
it entirely.

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

[Tetsuo Handa]

On 2024/10/03 11:45, John Johansen wrote:
>> But due to above-mentioned realities, your assertion no longer stands.
>> Kernel source itself might be open, but private keys cannot be open.
>> The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
>> negative impact on the user side, which cannot be a viable solution).
>>
>>
> Yes, and this is an intentional choice on the base of the distro about
> what they support and what is required to meet contractual obligations.

The reason Fedora cannot enable TOMOYO is lack of bandwidth.
You've just said "Bandwidth is a very real issue". Thus, I need a solution
that can solve the bandwidth problem. The question is how we can control
division of role (share the workload) in a secure manner.

> 
> Users are still free to build their own kernels they just don't get
> support or certification when using them.

Nobody can provide bandwidth (or infrastructure) for supporting their
locally built kernels.

>                                           Stopping the load of out of
> tree modules that aren't signed is in general good security policy.

Yes, distributors can prevent load of out-of-tree modules that aren't
signed. That is good for security. But building kernels locally cannot
utilize signed modules functionality. Also,

> 
> Let me be explicitly clear. If Tomoyo is by-passing module signing, and
> exporting the LSM interface to loadable modules Ubuntu will be forced
> to disable Tomoyo.

TOMOYO is one of in-tree modules that can be signed together when building
distribution kernels. Fedora can provide tomoyo.ko as a signed-but-unsupported
module (i.e. excluded from main kernel package that is supported by
distributors but provided as a separate package that is not supported by
distributors).

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

[John Johansen]

On 10/2/24 21:26, Tetsuo Handa wrote:
> On 2024/10/03 11:45, John Johansen wrote:
>>> But due to above-mentioned realities, your assertion no longer stands.
>>> Kernel source itself might be open, but private keys cannot be open.
>>> The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
>>> negative impact on the user side, which cannot be a viable solution).
>>>
>>>
>> Yes, and this is an intentional choice on the base of the distro about
>> what they support and what is required to meet contractual obligations.
> 
> The reason Fedora cannot enable TOMOYO is lack of bandwidth.

which is sadly a very valid argument. Coming from the distro side of things
it is a very real problem. I tend to advocate for giving the user choice
where we can but there is more than one occasion where Ubuntu has had
to declare bug bankruptcy on outstanding kernel bugs because the backlog
was impossible to handle.

> You've just said "Bandwidth is a very real issue". Thus, I need a solution
> that can solve the bandwidth problem. The question is how we can control
> division of role (share the workload) in a secure manner.
> 
I do understand that. The problem is that out of tree doesn't do that.
 From a distro perspective out of tree is more work, and is very problematic
from a code signing perspective.

Code signing isn't going away, if anything its become a requirement to
support the majority of users. Loading unsigned modules, code, even
bpf is a problem.

Sure individual users can disable secure boot etc but at the distro
level we need to support secure boot out of the box. Out of tree code
really just isn't compatible with this.

>>
>> Users are still free to build their own kernels they just don't get
>> support or certification when using them.
> 
> Nobody can provide bandwidth (or infrastructure) for supporting their
> locally built kernels.
> 
right

>>                                            Stopping the load of out of
>> tree modules that aren't signed is in general good security policy.
> 
> Yes, distributors can prevent load of out-of-tree modules that aren't
> signed. That is good for security. But building kernels locally cannot
> utilize signed modules functionality. Also,
> 
true. that is a limitation of the cryptography that is being used, and
I don't see a way to fix that

>>
>> Let me be explicitly clear. If Tomoyo is by-passing module signing, and
>> exporting the LSM interface to loadable modules Ubuntu will be forced
>> to disable Tomoyo.
> 
> TOMOYO is one of in-tree modules that can be signed together when building
> distribution kernels. Fedora can provide tomoyo.ko as a signed-but-unsupported
> module (i.e. excluded from main kernel package that is supported by
> distributors but provided as a separate package that is not supported by
> distributors).
> 
yes it can, it has chosen not to. As I have said before that is
a choice/political reason, not technical. I wish I had a solution to this
problem for you but I don't. What I can say is Tomoyo adding the ability to
load out of tree code that isn't signed is going to force Ubuntu to do
the same and disable it. I really don't want to do that, I would rather
leave the choice available to our users.

It may be a trade-off worth making for you/Tomoyo if it fixed your
problem with RHEL/Fedora but I don't see it fixing that problem either.

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

[Tetsuo Handa]

On 2024/10/03 14:35, John Johansen wrote:
> I do understand that. The problem is that out of tree doesn't do that.
> From a distro perspective out of tree is more work, and is very problematic
> from a code signing perspective.
> 
> Code signing isn't going away, if anything its become a requirement to
> support the majority of users. Loading unsigned modules, code, even
> bpf is a problem.

Confused. If use of BPF is a problem, use of BPF-LSM is also a problem?
If one were able to implement security modules using BPF-LSM, such modules
are headache for distributors? If so, BPF based LSM modules can't be a
candidate for replacing C based LSM modules...

> 
> Sure individual users can disable secure boot etc but at the distro
> level we need to support secure boot out of the box. Out of tree code
> really just isn't compatible with this.

More we want to enforce protecting with module signing, more we need to make
whatever code built-in and run in the kernel space. Upstream-first pressure
will push whatever code for inclusion into the upstream kernel.



>> TOMOYO is one of in-tree modules that can be signed together when building
>> distribution kernels. Fedora can provide tomoyo.ko as a signed-but-unsupported
>> module (i.e. excluded from main kernel package that is supported by
>> distributors but provided as a separate package that is not supported by
>> distributors).
>>
> yes it can, it has chosen not to. As I have said before that is
> a choice/political reason, not technical. I wish I had a solution to this
> problem for you but I don't.

What does "it" referring to? Fedora has chosen not to build TOMOYO into Fedora's
vmlinux. But I haven't heard from Fedora that Fedora won't ship tomoyo.ko as a
separate package.

>                              What I can say is Tomoyo adding the ability to
> load out of tree code that isn't signed is going to force Ubuntu to do
> the same and disable it. I really don't want to do that, I would rather
> leave the choice available to our users.

How is tomoyo.ko connected to loading of out-of-tree code? If the module signing
can prevent unsigned modules from loading, where is the possibility of loading
unsigned LSM modules even if LSM hooks are exported to loadable modules?

 From module signing perspective, there will be no difference between the LSM
framework exports LSM hooks and TOMOYO exports LSM hooks. And
https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp
leaves the choice available to distro users. Why not acceptable?

By some chance..., can't module signing prevent any code (both in-tree and
out-of-tree) that is not signed from loading !?

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

[Tetsuo Handa]

On 2024/10/03 15:16, Tetsuo Handa wrote:
>>> TOMOYO is one of in-tree modules that can be signed together when building
>>> distribution kernels. Fedora can provide tomoyo.ko as a signed-but-unsupported
>>> module (i.e. excluded from main kernel package that is supported by
>>> distributors but provided as a separate package that is not supported by
>>> distributors).
>>>
>> yes it can, it has chosen not to. As I have said before that is
>> a choice/political reason, not technical. I wish I had a solution to this
>> problem for you but I don't.
> 
> What does "it" referring to? Fedora has chosen not to build TOMOYO into Fedora's
> vmlinux. But I haven't heard from Fedora that Fedora won't ship tomoyo.ko as a
> separate package.

Currently, a Linux distributor is an entity that provides kernel program and
userspace program. But as the kernel code signing getting more important,
the role of a Linux distributor regarding the kernel program might change as
below?

Currently, people expect that "distributor takes care of handling all bugs
that happens with kernel code built by that distributor". Due to bandwidth
problem, distributor needs to disable kernel code which that distributor cannot
take care of bugs. My understanding is that some distributors started providing
separated kernel packages; the kernel package which that distributor can take
care of bugs and the kernel package which that distributor cannot take care of
bugs. The tomoyo.ko change is intended for being included in the latter package
if that distributor cannot include in the former package.

Since distributor needs to sign kernel code, I think this separation is becoming
more inevitable. That is, people might need to change their expectation to that
"distributor takes care of handling bugs that happens with kernel code in the
former package, and somebody takes care of handling bugs that happens with kernel
code in the latter package", and distributor's role is to compile as many kernel
code as possible and sign all compiled kernel code so that the kernel code is
compiled and shipped (and not tampered) by known entities; something like SSL
certificates providers.

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

[Dr. Greg]

On Wed, Oct 02, 2024 at 10:35:27PM -0700, John Johansen wrote:

Good morning, I hope the day is going well for everyone.

> On 10/2/24 21:26, Tetsuo Handa wrote:
> >On 2024/10/03 11:45, John Johansen wrote:
> >>>But due to above-mentioned realities, your assertion no longer stands.
> >>>Kernel source itself might be open, but private keys cannot be open.
> >>>The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
> >>>negative impact on the user side, which cannot be a viable solution).
> >>>
> >>>
> >>Yes, and this is an intentional choice on the base of the distro about
> >>what they support and what is required to meet contractual obligations.
> >
> >The reason Fedora cannot enable TOMOYO is lack of bandwidth.

> which is sadly a very valid argument. Coming from the distro side of
> things it is a very real problem. I tend to advocate for giving the
> user choice where we can but there is more than one occasion where
> Ubuntu has had to declare bug bankruptcy on outstanding kernel bugs
> because the backlog was impossible to handle.

Understand the concept of lack of bandwidth.

Had a 40 hour week in as of 0800 yesterday morning and the end of the
week isn't even remotely in sight.

> >You've just said "Bandwidth is a very real issue". Thus, I need a solution
> >that can solve the bandwidth problem. The question is how we can control
> >division of role (share the workload) in a secure manner.

> I do understand that. The problem is that out of tree doesn't do that.
> From a distro perspective out of tree is more work, and is very problematic
> from a code signing perspective.
> 
> Code signing isn't going away, if anything its become a requirement to
> support the majority of users. Loading unsigned modules, code, even
> bpf is a problem.
> 
> Sure individual users can disable secure boot etc but at the distro
> level we need to support secure boot out of the box. Out of tree code
> really just isn't compatible with this.

Not relevant right now but I do remember, personally at a conference,
Stallman railing on about the threat of signed code and what it
represents with respect to software and device freedom.

And here we are....

> >>Users are still free to build their own kernels they just don't get
> >>support or certification when using them.
> >
> >Nobody can provide bandwidth (or infrastructure) for supporting their
> >locally built kernels.

> right

> >>                                           Stopping the load of out of
> >>tree modules that aren't signed is in general good security policy.
> >
> >Yes, distributors can prevent load of out-of-tree modules that aren't
> >signed. That is good for security. But building kernels locally cannot
> >utilize signed modules functionality. Also,

> true. that is a limitation of the cryptography that is being used, and
> I don't see a way to fix that

> >>Let me be explicitly clear. If Tomoyo is by-passing module signing, and
> >>exporting the LSM interface to loadable modules Ubuntu will be forced
> >>to disable Tomoyo.
> >
> >TOMOYO is one of in-tree modules that can be signed together when building
> >distribution kernels. Fedora can provide tomoyo.ko as a 
> >signed-but-unsupported
> >module (i.e. excluded from main kernel package that is supported by
> >distributors but provided as a separate package that is not supported by
> >distributors).

> yes it can, it has chosen not to. As I have said before that is a
> choice/political reason, not technical. I wish I had a solution to
> this problem for you but I don't. What I can say is Tomoyo adding
> the ability to load out of tree code that isn't signed is going to
> force Ubuntu to do the same and disable it. I really don't want to
> do that, I would rather leave the choice available to our users.
>
> It may be a trade-off worth making for you/Tomoyo if it fixed your
> problem with RHEL/Fedora but I don't see it fixing that problem
> either.

Not much bandwidth for the rest of the day but I wanted to get this
question/issue out to get some feedback for later tonight,
particularly from your perspective John.

We saw these issues coming about four years ago, which is why we
decided to take a deep breath and bring TSEM out of private use to a
wider audience, it isn't a 'pet project' as it has been referred to.
Not sure we would do that again but that is an issue for another day.

TSEM is based on the notion of having a generic modeling architecture
for the LSM.  I know that Casey bristles at the notion of us saying
'model', but we can prosecute that argument in intimate detail at
another time.

We would best characterize TSEM as a 'swiss army knife' for
interpreting kernel security events.  You can run the event
interpretation in the kernel, in userspace, in a hardware device or up
in the cloud.

After watching Tetsuo's concerns over the last year we dropped the
loadable module support into TSEM for the V4 release:

https://lore.kernel.org/linux-security-module/20240826103728.3378-1-greg@enjellic.com/T/#t

This offers the ability to run the interpretation model via code
implemented in a loadable module.  BPF is also an option but we are
keeping things simple at this point.

So we use the standard loadable module architecture.  We offer the
ability to lock further model loads or unloads after a set of models
have been loaded and the option to completely disable any loadable
models at boot, independent of the general kernel loadable module
state.

It doesn't fully fix Tetsuo's problem, given that a distribution could
compile out TSEM, just like it compiles out Tomoyo, I think we all
agree there is no fix to that problem.  However, if the security bigs
like CrowdStrike, PaloAlto and others, understand that it allows EDR
telemetry and surveillance to be implemented on Linux without having
to install a high privilege or kernel based agent, it makes not having
it in the kernel less attractive.

Just for the sake of advancing these conversations, we are throwing
some bandwidth into implementing Tomoyo as a TSEM loadable module to
get some further insight on the tractability of something like this.

With your distributor hat on does an architecture like this offend
your security sensibilities?

Like it or agree with it, we seem to be standing at a reasonably
important inflection point for Linux, conversations probably suitable
for a 'Summit' type event.

Will look forward to your thoughts.

Have a good day.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

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

[Dr. Greg]

On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:

> 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

Just going out the door and saw this e-mail

Your e-mail crossed with one I just sent over in the kernel code
loading side of this thread/debate.

Will look forward to seeing your thoughts there.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

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

[Dr. Greg]

On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:

Hi, I hope the week has gone well for everyone.

> 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

I don't disagree and have publically stated that a number of times
over the last 10 months or so that this issue has been raging,
including in e-mail to Tetsuo himself.

Our opinion or ACK doesn't matter much in the grand scheme of things,
but Paul can feel free to take his black sharpie pen and place a mark
in the column that indicates that it is in everyone's interest to have
a standard framework for security event dispatch, on our behalf.

That being said, if we are actually serious about responding properly
to this event/crisis, we need to step back and have an intellectually
honest engineering discussing surrounding the following question:

Has the threat environment, its significance to society and industry
and the scale and scope of the solutions needed to mount a response to
it, changed since the inception of the LSM 22 years ago?

Colleagues I have in the counseling industry tell me that the first
step in resolving a problem is recognizing that there is a problem.

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

With respect to bandwidth there are two problems that need to addressed:

1.) The amount of time and talent it takes for developers to implement
security policies with mandatory enforcement capabilities.

2.) The ability to implement security technology solutions on linux,
based on a standardized infrastructure, in less than 4-5+ year
timeframes.

The third problem to be addressed, and you acknowledge it above, is
that there needs to be a flexible pathway for security innovation on
Linux that doesn't require broad based consensus and yet doesn't
imperil the kernel.

This latter issue is the most fundamental problem with security on
Linux and something that Linus has publically complained about
multiple times, as we all know.

With TSEM we placed a design on the table, influenced by individuals
with significant experience in the field and its challenges, that was
a legitimate attempt to address these issues, including the problem
that Tetuso has.  Unfortunately it sat on the cutting room floor for
20 months without even a legitimate technical discussion as to its
motivation and design and the fact that it could have provided a
method to derail this current crisis/controversy.

We fully recognize and respect the bandwidth crisis.  If it is as bad
as everyone claims it is, and there is no reason to assume otherwise,
then we need to acknowledge and address this issue as one of the two
roots of our problem, if security innovation on Linux is to remain
even remotely relevant and healthy.

We appreciate your willingness to review TSEM sometime down the road
and will look forward to your thoughts.

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

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

[Paul Moore]

On Fri, Oct 4, 2024 at 2:40 PM Dr. Greg <greg@enjellic.com> wrote:
> On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:
> > On 10/2/24 03:38, Dr. Greg 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@paul-moore.com> wrote:

...

> The third problem to be addressed, and you acknowledge it above, is
> that there needs to be a flexible pathway for security innovation on
> Linux that doesn't require broad based consensus and yet doesn't
> imperil the kernel.

The new LSM guidelines are documented at the URL below (and available
in the README.md file of any cloned LSM tree), the document is also
linked from the MAINTAINERS file:

https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-guidelines

The guidelines were developed last summer on the LSM mailing list with
input and edits from a number of LSM developers.

https://lore.kernel.org/linux-security-module/CAHC9VhRsxARUsFcJC-5zp9pX8LWbKQLE4vW+S6n-PMG5XJZtDA@mail.gmail.com

-- 
paul-moore.com

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

[Dr. Greg]

On Fri, Oct 04, 2024 at 02:58:57PM -0400, Paul Moore wrote:

Good evening, I hope the week has gone well for everyone.

> On Fri, Oct 4, 2024 at 2:40???PM Dr. Greg <greg@enjellic.com> wrote:
> > On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:
> > > On 10/2/24 03:38, Dr. Greg 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@paul-moore.com> wrote:
> 
> ...
> 
> > The third problem to be addressed, and you acknowledge it above, is
> > that there needs to be a flexible pathway for security innovation on
> > Linux that doesn't require broad based consensus and yet doesn't
> > imperil the kernel.

> The new LSM guidelines are documented at the URL below (and
> available in the README.md file of any cloned LSM tree), the
> document is also linked from the MAINTAINERS file:
>
> https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-guidelines
>
> The guidelines were developed last summer on the LSM mailing list
> with input and edits from a number of LSM developers.
>
> https://lore.kernel.org/linux-security-module/CAHC9VhRsxARUsFcJC-5zp9pX8LWbKQLE4vW+S6n-PMG5XJZtDA@mail.gmail.com

We are intimately familiar with those documents.

Our reference was to the need for a technical solution, not political
medicaments.

> paul-moore.com

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

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

[John Johansen]

On 10/2/24 23:16, Tetsuo Handa wrote:
> On 2024/10/03 14:35, John Johansen wrote:
>> I do understand that. The problem is that out of tree doesn't do that.
>>  From a distro perspective out of tree is more work, and is very problematic
>> from a code signing perspective.
>>
>> Code signing isn't going away, if anything its become a requirement to
>> support the majority of users. Loading unsigned modules, code, even
>> bpf is a problem.
> 
> Confused. If use of BPF is a problem, use of BPF-LSM is also a problem?

yes it is. Pressures being what they are, it is enabled for some of our
kernels. Signed BPF would be required to get it available every where.

> If one were able to implement security modules using BPF-LSM, such modules
> are headache for distributors? If so, BPF based LSM modules can't be a
> candidate for replacing C based LSM modules...
> 

I have never argued they were. But they are currently the only solution for
out of tree LSM modules if you don't want to rebuild the kernel.

>>
>> Sure individual users can disable secure boot etc but at the distro
>> level we need to support secure boot out of the box. Out of tree code
>> really just isn't compatible with this.
> 
> More we want to enforce protecting with module signing, more we need to make
> whatever code built-in and run in the kernel space. Upstream-first pressure
> will push whatever code for inclusion into the upstream kernel.
> 
> 
> 
>>> TOMOYO is one of in-tree modules that can be signed together when building
>>> distribution kernels. Fedora can provide tomoyo.ko as a signed-but-unsupported
>>> module (i.e. excluded from main kernel package that is supported by
>>> distributors but provided as a separate package that is not supported by
>>> distributors).
>>>
>> yes it can, it has chosen not to. As I have said before that is
>> a choice/political reason, not technical. I wish I had a solution to this
>> problem for you but I don't.
> 
> What does "it" referring to? Fedora has chosen not to build TOMOYO into Fedora's
> vmlinux. But I haven't heard from Fedora that Fedora won't ship tomoyo.ko as a
> separate package.
> 
yeah fedora/RHEL, they don't build apparmor either. And I do not believe that
building tomoyo.ko will get them to ship it in a separate package. That separate
package is more work than a builtin tomoyo and the kernel memory savings are
minimal.

With KP's performance patch the performance overhead of a builtin tomoyo is
negligible.

>>                               What I can say is Tomoyo adding the ability to
>> load out of tree code that isn't signed is going to force Ubuntu to do
>> the same and disable it. I really don't want to do that, I would rather
>> leave the choice available to our users.
> 
> How is tomoyo.ko connected to loading of out-of-tree code? If the module signing
> can prevent unsigned modules from loading, where is the possibility of loading
> unsigned LSM modules even if LSM hooks are exported to loadable modules?
> 

sorry was tired and in rush, and dumping in the other worries I have here. Exporting
symbols itself has nothing to do with module signing. However as Kees pointed
out in another email it does become an attack target.

The other one is I don't believe tomoyo,ko is going to get built as part of
the fedora/RH infrastructure. Which means module signing will block it. You went
for a "technical" solution on the symbols export, by-passing the community.
What is the next technical solution to get around module signing. Over the top,
paranoid, maybe. Do I think its highly unlikely, yes, but it became a worry as
soon as you pushed this patchset.

>   From module signing perspective, there will be no difference between the LSM
> framework exports LSM hooks and TOMOYO exports LSM hooks. And
> https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp
> leaves the choice available to distro users. Why not acceptable?
> 
> By some chance..., can't module signing prevent any code (both in-tree and
> out-of-tree) that is not signed from loading !?
> 
as long as it goes through the module infrastructure sure.

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

[John Johansen]

On 10/3/24 05:59, Tetsuo Handa wrote:
> On 2024/10/03 15:16, Tetsuo Handa wrote:
>>>> TOMOYO is one of in-tree modules that can be signed together when building
>>>> distribution kernels. Fedora can provide tomoyo.ko as a signed-but-unsupported
>>>> module (i.e. excluded from main kernel package that is supported by
>>>> distributors but provided as a separate package that is not supported by
>>>> distributors).
>>>>
>>> yes it can, it has chosen not to. As I have said before that is
>>> a choice/political reason, not technical. I wish I had a solution to this
>>> problem for you but I don't.
>>
>> What does "it" referring to? Fedora has chosen not to build TOMOYO into Fedora's
>> vmlinux. But I haven't heard from Fedora that Fedora won't ship tomoyo.ko as a
>> separate package.
> 
> Currently, a Linux distributor is an entity that provides kernel program and
> userspace program. But as the kernel code signing getting more important,
> the role of a Linux distributor regarding the kernel program might change as
> below?
> 
> Currently, people expect that "distributor takes care of handling all bugs
> that happens with kernel code built by that distributor". Due to bandwidth
> problem, distributor needs to disable kernel code which that distributor cannot
> take care of bugs. My understanding is that some distributors started providing
> separated kernel packages; the kernel package which that distributor can take
> care of bugs and the kernel package which that distributor cannot take care of
> bugs. The tomoyo.ko change is intended for being included in the latter package
> if that distributor cannot include in the former package.
> 
honestly its easier to just build a separate kernel package with tomoyo builtin.
Module packages can be done, but they are a pita.

> Since distributor needs to sign kernel code, I think this separation is becoming
> more inevitable. That is, people might need to change their expectation to that
> "distributor takes care of handling bugs that happens with kernel code in the
> former package, and somebody takes care of handling bugs that happens with kernel
> code in the latter package", and distributor's role is to compile as many kernel
> code as possible and sign all compiled kernel code so that the kernel code is
> compiled and shipped (and not tampered) by known entities; something like SSL
> certificates providers.
> 
Sure. Distribution already tell users they aren't using supported stuff. Ubuntu
builds in selinux, tomoyo, smack. We get a bug we tell them it is community
supported.

That has some overhead, but really not that much more than responding to the
bugs where users ask for feature X to be enabled. Or how to build a kernel with
feature X, ...

Ubuntu made a different decision than fedora around how best to support users.
I am not going to argue its right or wrong, just different. Again getting a
distro to change a config/stance is a political problem, not technical.

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

[John Johansen]

On 10/3/24 08:39, Dr. Greg wrote:
> On Wed, Oct 02, 2024 at 10:35:27PM -0700, John Johansen wrote:
> 
> Good morning, I hope the day is going well for everyone.
> 
>> On 10/2/24 21:26, Tetsuo Handa wrote:
>>> On 2024/10/03 11:45, John Johansen wrote:
>>>>> But due to above-mentioned realities, your assertion no longer stands.
>>>>> Kernel source itself might be open, but private keys cannot be open.
>>>>> The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
>>>>> negative impact on the user side, which cannot be a viable solution).
>>>>>
>>>>>
>>>> Yes, and this is an intentional choice on the base of the distro about
>>>> what they support and what is required to meet contractual obligations.
>>>
>>> The reason Fedora cannot enable TOMOYO is lack of bandwidth.
> 
>> which is sadly a very valid argument. Coming from the distro side of
>> things it is a very real problem. I tend to advocate for giving the
>> user choice where we can but there is more than one occasion where
>> Ubuntu has had to declare bug bankruptcy on outstanding kernel bugs
>> because the backlog was impossible to handle.
> 
> Understand the concept of lack of bandwidth.
> 
> Had a 40 hour week in as of 0800 yesterday morning and the end of the
> week isn't even remotely in sight.

yeah I know that one all too well, I hit 40 hours some time Wednesday
morning.

> 
>>> You've just said "Bandwidth is a very real issue". Thus, I need a solution
>>> that can solve the bandwidth problem. The question is how we can control
>>> division of role (share the workload) in a secure manner.
> 
>> I do understand that. The problem is that out of tree doesn't do that.
>>  From a distro perspective out of tree is more work, and is very problematic
>> from a code signing perspective.
>>
>> Code signing isn't going away, if anything its become a requirement to
>> support the majority of users. Loading unsigned modules, code, even
>> bpf is a problem.
>>
>> Sure individual users can disable secure boot etc but at the distro
>> level we need to support secure boot out of the box. Out of tree code
>> really just isn't compatible with this.
> 
> Not relevant right now but I do remember, personally at a conference,
> Stallman railing on about the threat of signed code and what it
> represents with respect to software and device freedom.
> 
> And here we are....
> 
>>>> Users are still free to build their own kernels they just don't get
>>>> support or certification when using them.
>>>
>>> Nobody can provide bandwidth (or infrastructure) for supporting their
>>> locally built kernels.
> 
>> right
> 
>>>>                                            Stopping the load of out of
>>>> tree modules that aren't signed is in general good security policy.
>>>
>>> Yes, distributors can prevent load of out-of-tree modules that aren't
>>> signed. That is good for security. But building kernels locally cannot
>>> utilize signed modules functionality. Also,
> 
>> true. that is a limitation of the cryptography that is being used, and
>> I don't see a way to fix that
> 
>>>> Let me be explicitly clear. If Tomoyo is by-passing module signing, and
>>>> exporting the LSM interface to loadable modules Ubuntu will be forced
>>>> to disable Tomoyo.
>>>
>>> TOMOYO is one of in-tree modules that can be signed together when building
>>> distribution kernels. Fedora can provide tomoyo.ko as a
>>> signed-but-unsupported
>>> module (i.e. excluded from main kernel package that is supported by
>>> distributors but provided as a separate package that is not supported by
>>> distributors).
> 
>> yes it can, it has chosen not to. As I have said before that is a
>> choice/political reason, not technical. I wish I had a solution to
>> this problem for you but I don't. What I can say is Tomoyo adding
>> the ability to load out of tree code that isn't signed is going to
>> force Ubuntu to do the same and disable it. I really don't want to
>> do that, I would rather leave the choice available to our users.
>>
>> It may be a trade-off worth making for you/Tomoyo if it fixed your
>> problem with RHEL/Fedora but I don't see it fixing that problem
>> either.
> 
> Not much bandwidth for the rest of the day but I wanted to get this
> question/issue out to get some feedback for later tonight,
> particularly from your perspective John.
> 
> We saw these issues coming about four years ago, which is why we
> decided to take a deep breath and bring TSEM out of private use to a
> wider audience, it isn't a 'pet project' as it has been referred to.
> Not sure we would do that again but that is an issue for another day.
> 
> TSEM is based on the notion of having a generic modeling architecture
> for the LSM.  I know that Casey bristles at the notion of us saying
> 'model', but we can prosecute that argument in intimate detail at
> another time.
> 
> We would best characterize TSEM as a 'swiss army knife' for
> interpreting kernel security events.  You can run the event
> interpretation in the kernel, in userspace, in a hardware device or up
> in the cloud.
> 
> After watching Tetsuo's concerns over the last year we dropped the
> loadable module support into TSEM for the V4 release:
> 
> https://lore.kernel.org/linux-security-module/20240826103728.3378-1-greg@enjellic.com/T/#t
> 
> This offers the ability to run the interpretation model via code
> implemented in a loadable module.  BPF is also an option but we are
> keeping things simple at this point.
> 
> So we use the standard loadable module architecture.  We offer the
> ability to lock further model loads or unloads after a set of models
> have been loaded and the option to completely disable any loadable
> models at boot, independent of the general kernel loadable module
> state.
> 
> It doesn't fully fix Tetsuo's problem, given that a distribution could
> compile out TSEM, just like it compiles out Tomoyo, I think we all
> agree there is no fix to that problem.  However, if the security bigs
> like CrowdStrike, PaloAlto and others, understand that it allows EDR
> telemetry and surveillance to be implemented on Linux without having
> to install a high privilege or kernel based agent, it makes not having
> it in the kernel less attractive.
> 
> Just for the sake of advancing these conversations, we are throwing
> some bandwidth into implementing Tomoyo as a TSEM loadable module to
> get some further insight on the tractability of something like this.
> 
> With your distributor hat on does an architecture like this offend
> your security sensibilities?
> 
> Like it or agree with it, we seem to be standing at a reasonably
> important inflection point for Linux, conversations probably suitable
> for a 'Summit' type event.
> 
> Will look forward to your thoughts.
> 
honestly it worries me, but that is more a vague general worry about
any generic architecture that you can build on top of. Take BPF, it
has a whole host of issues, that make it very challenging, like
spectre gadgets, and getting its verifier correct for everything.
There is a lot of complexity there making it a challenge to evaluate.

I really need to dig into the details of TSEM before I can give a better
response.




> Have a good day.
> 
> As always,
> Dr. Greg
> 
> The Quixote Project - Flailing at the Travails of Cybersecurity
>                https://github.com/Quixote-Project

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

[John Johansen]

On 10/3/24 08:43, Dr. Greg wrote:
> On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:
> 
>> 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
> 
> Just going out the door and saw this e-mail
> 
> Your e-mail crossed with one I just sent over in the kernel code
> loading side of this thread/debate.
> 
> Will look forward to seeing your thoughts there.
> 
This one is a hard problem. I don't have a good solution. We are
pushing up against lots of constraints: performance (see KP's patch),
the need to get rid of/reduce use of indirect branches because of
spectre (again performance but also brittleness), the desire to
make the LSM less of a target for kernel compromises (ro after init).
The need for code signing and integrity. The need for common interfaces
(LSM syscalls), to avoid the interface sins of the past.

This makes loadable LSMs troublesome at best and I concede maybe
impossible politically.

I am not entirely opposed to the approach that Tetsuo took. Its
interesting, and I wouldn't have minded it being explored more as a way
to extend the LSM, but as part of the LSM, not in crammed into an
individual LSM.

The performance hit for its use I am willing to accept because,
it only happens if it is enabled. So it would be easy to build it
in and just not enable it by default.

It would still have to show how to deal with ro of the hooks, make
sure we aren't introducing new spectre gadgets, and also have a
way to integrate with LSM syscalls, and probably a few other
things I am missing.

These are all things that would need to be discussed on list.


> As always,
> Dr. Greg
> 
> The Quixote Project - Flailing at the Travails of Cybersecurity
>                https://github.com/Quixote-Project

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

[Paul Moore]

On Fri, Oct 4, 2024 at 10:34 PM Dr. Greg <greg@enjellic.com> wrote:
> On Fri, Oct 04, 2024 at 02:58:57PM -0400, Paul Moore wrote:
> > On Fri, Oct 4, 2024 at 2:40???PM Dr. Greg <greg@enjellic.com> wrote:
> > > On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:
> > > > On 10/2/24 03:38, Dr. Greg 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@paul-moore.com> wrote:
> >
> > ...
> >
> > > The third problem to be addressed, and you acknowledge it above, is
> > > that there needs to be a flexible pathway for security innovation on
> > > Linux that doesn't require broad based consensus and yet doesn't
> > > imperil the kernel.
>
> > The new LSM guidelines are documented at the URL below (and
> > available in the README.md file of any cloned LSM tree), the
> > document is also linked from the MAINTAINERS file:
> >
> > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-guidelines
> >
> > The guidelines were developed last summer on the LSM mailing list
> > with input and edits from a number of LSM developers.
> >
> > https://lore.kernel.org/linux-security-module/CAHC9VhRsxARUsFcJC-5zp9pX8LWbKQLE4vW+S6n-PMG5XJZtDA@mail.gmail.com
>
> We are intimately familiar with those documents.
>
> Our reference was to the need for a technical solution, not political
> medicaments.

Seeing that document as a purely political solution to the challenge
of gaining acceptance for a new LSM is a telling perspective, and not
an accurate one as far as I'm concerned.  The document spells out a
number of things that new LSMs should strive to satisfy if they want
to be included in the upstream Linux kernel; it's intended as guidance
both for the development of new LSMs as well as their review.

If those guidelines are too restrictive or otherwise stifling, you are
always welcome to suggest changes on the LSM list; that is how the doc
was established and that is how we'll keep it current and resonable.

However, if you find yourself objecting to the guidelines simply
because they are trying your patience, or you find that the technical
reviews driven by those guidelines are incorrect, but are unable to
properly respond in a way that satisfies the reviewer, then the
upstream Linux kernel may not be the best place for your LSM.

-- 
paul-moore.com

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

[Dr. Greg]

On Sat, Oct 05, 2024 at 12:21:31PM -0400, Paul Moore wrote:

Good morning, I hope the week is starting well for everyone.

> On Fri, Oct 4, 2024 at 10:34???PM Dr. Greg <greg@enjellic.com> wrote:
> > On Fri, Oct 04, 2024 at 02:58:57PM -0400, Paul Moore wrote:
> > > On Fri, Oct 4, 2024 at 2:40???PM Dr. Greg <greg@enjellic.com> wrote:
> > > > On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:
> > > > > On 10/2/24 03:38, Dr. Greg 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@paul-moore.com> wrote:
> > >
> > > ...
> > >
> > > > The third problem to be addressed, and you acknowledge it above, is
> > > > that there needs to be a flexible pathway for security innovation on
> > > > Linux that doesn't require broad based consensus and yet doesn't
> > > > imperil the kernel.
> >
> > > The new LSM guidelines are documented at the URL below (and
> > > available in the README.md file of any cloned LSM tree), the
> > > document is also linked from the MAINTAINERS file:
> > >
> > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-guidelines
> > >
> > > The guidelines were developed last summer on the LSM mailing list
> > > with input and edits from a number of LSM developers.
> > >
> > > https://lore.kernel.org/linux-security-module/CAHC9VhRsxARUsFcJC-5zp9pX8LWbKQLE4vW+S6n-PMG5XJZtDA@mail.gmail.com
> >
> > We are intimately familiar with those documents.
> >
> > Our reference was to the need for a technical solution, not political
> > medicaments.

> Seeing that document as a purely political solution to the challenge
> of gaining acceptance for a new LSM is a telling perspective, and not
> an accurate one as far as I'm concerned.  The document spells out a
> number of things that new LSMs should strive to satisfy if they want
> to be included in the upstream Linux kernel; it's intended as guidance
> both for the development of new LSMs as well as their review.
> 
> If those guidelines are too restrictive or otherwise stifling, you are
> always welcome to suggest changes on the LSM list; that is how the doc
> was established and that is how we'll keep it current and resonable.
> 
> However, if you find yourself objecting to the guidelines simply
> because they are trying your patience, or you find that the technical
> reviews driven by those guidelines are incorrect, but are unable to
> properly respond in a way that satisfies the reviewer, then the
> upstream Linux kernel may not be the best place for your LSM.

The document is an embodiment of a political process, let me take a
swing at defining what it is:

It is a collaboratively developed instrument for establishing
normative guidelines and practices, among a diverse group of
individuals with varying goals and objectives, who desire to cooperate
to create an environment that supports the resolution of conflicts in
the pursuit of individual objectives while maintaining a common good.

I think we have all been around long enough to understand that Linux
kernel development and distribution is a study in technical politics,
probably more so than ever.

You don't have to take my word for it.  Our Quixote team is fortunate
enough to have as a member, a valued consigliere, who hangs both a J.D
and a Ph.D. off the end of her name.  The latter in political science
whose 600+ page dissertation studied, among other issues, the role of
mediation in a legal system.

She was influenced by a top constitutional scholar, and as we all
know, the US constitution was a document designed to mediate a
political process in the pursuit of the common good.

We could get an opinion from her, if you want to take on her hourly
rates.  I'm pretty confident she would conclude that this is a
political process and the ANN document is an instrument for mediating
that process.

For the record, we have no issues with the document.  It is a bit
light on rights of participants in the process and requirements for
leadership, but that is a subject for another day and perhaps the
kernel community at large.

Interestingly enough, and relevant to these conversations, is that
Tetsuo has consistently called out the 'patent' requirements of the
document as problematic.  Once again, a subject for another
conversation.

Citing the document in response to our suggestion that there needs to
be a flexible pathway for security innovation, that doesn't require
consensus, misses the point we were making.

As the TOMOYO incident points out, requiring the need to have kernel
resident code to implement a security architecture that samples LSM
events is problematic and will probably become more as time goes on.

From a commercial perspective, the Linux distributors are being forced
into code signing due to security issues.  As this incident has
demonstrated, the effect of that is to limit choice in security
solutions to what the distributions feel they can or want to support.

From a technical perspective, history has clearly demonstrated that
security engineers have varying and unique ideas on how security
should be implemented, much to the long stated consternation of Linus
himself.  The LSM is a study in the fact that people cannot agree on
how security should be implemented.

The existence of the ANN document doesn't address either of these
issues.

It addresses how to participate in the process of getting a security
implementation into the kernel proper, which this incident has clearly
demonstrated is the problematic requirement.

We will ultimately never 'fix' this problem because it is a political
problem, given that distributions either want to limit choice for
business purposes or are being forced into it by the current threat
environment.

So the path forward to address this problem, the best that we can hope
for, is to develop an architecture that minimizes the need for
consensus on how to implement a security architecture.

Tetsuo has placed one idea on the table, we will see where that goes
and how long it ultimately takes.

As I've stated before, we saw this coming about four years ago and
TSEM was designed to provide an architecture that minimizes the need
for consensus on how to do security.

We will litigate elsewhere the current state of issues we have
experienced with that.

> paul-moore.com

Have a good week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

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

[Paul Moore]

On Mon, Oct 7, 2024 at 7:22 AM Dr. Greg <greg@enjellic.com> wrote:
> On Sat, Oct 05, 2024 at 12:21:31PM -0400, Paul Moore wrote:
> > On Fri, Oct 4, 2024 at 10:34???PM Dr. Greg <greg@enjellic.com> wrote:
> > > On Fri, Oct 04, 2024 at 02:58:57PM -0400, Paul Moore wrote:
> > > > On Fri, Oct 4, 2024 at 2:40???PM Dr. Greg <greg@enjellic.com> wrote:
> > > > > On Wed, Oct 02, 2024 at 07:27:47PM -0700, John Johansen wrote:
> > > > > > On 10/2/24 03:38, Dr. Greg 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@paul-moore.com> wrote:
> > > >
> > > > ...
> > > >
> > > > > The third problem to be addressed, and you acknowledge it above, is
> > > > > that there needs to be a flexible pathway for security innovation on
> > > > > Linux that doesn't require broad based consensus and yet doesn't
> > > > > imperil the kernel.
> > >
> > > > The new LSM guidelines are documented at the URL below (and
> > > > available in the README.md file of any cloned LSM tree), the
> > > > document is also linked from the MAINTAINERS file:
> > > >
> > > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-guidelines
> > > >
> > > > The guidelines were developed last summer on the LSM mailing list
> > > > with input and edits from a number of LSM developers.
> > > >
> > > > https://lore.kernel.org/linux-security-module/CAHC9VhRsxARUsFcJC-5zp9pX8LWbKQLE4vW+S6n-PMG5XJZtDA@mail.gmail.com
> > >
> > > We are intimately familiar with those documents.
> > >
> > > Our reference was to the need for a technical solution, not political
> > > medicaments.
>
> > Seeing that document as a purely political solution to the challenge
> > of gaining acceptance for a new LSM is a telling perspective, and not
> > an accurate one as far as I'm concerned.  The document spells out a
> > number of things that new LSMs should strive to satisfy if they want
> > to be included in the upstream Linux kernel; it's intended as guidance
> > both for the development of new LSMs as well as their review.
> >
> > If those guidelines are too restrictive or otherwise stifling, you are
> > always welcome to suggest changes on the LSM list; that is how the doc
> > was established and that is how we'll keep it current and resonable.
> >
> > However, if you find yourself objecting to the guidelines simply
> > because they are trying your patience, or you find that the technical
> > reviews driven by those guidelines are incorrect, but are unable to
> > properly respond in a way that satisfies the reviewer, then the
> > upstream Linux kernel may not be the best place for your LSM.
>
> The document is an embodiment of a political process, let me take a
> swing at defining what it is:

It's a shame that such a pedantic response failed to take note that
the first sentence in my original comment on the doc never claimed
there wasn't a political aspect, only that to consider it entirely, or
"purely", political is not accurate in my opinion.

Of course you're welcome to believe whatever you like about the
document, its intent, etc. as that is no business of mine outside a
mischaracterization of my own comments.  I think that's about all I've
got to say on that issue right now.

> So the path forward to address this problem, the best that we can hope
> for, is to develop an architecture that minimizes the need for
> consensus on how to implement a security architecture.
>
> Tetsuo has placed one idea on the table, we will see where that goes
> and how long it ultimately takes.

I have yet to see any patches over the past year or two changing how
LSMs are registered with the LSM framework from Tetsuo that are
acceptable upstream.

-- 
paul-moore.com

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

[Dr. Greg]

On Wed, Oct 02, 2024 at 10:35:58AM -0400, Paul Moore wrote:

Good morning, I hope the day is starting well for everyone.

Some clarifications regarding the current challenges to LSM review.

> On Wed, Oct 2, 2024 at 6:38???AM Dr. Greg <greg@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@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.

We would certainly concur and fall decidedly on the side of minimizing
any potential negative impacts to changes in the LSM.  One of our
areas of primary focus is on critical infrastructure systems, so we
are laser focused on both simplicity and high reliability.

That is why TSEM was designed to be an LSM that implements generic
security modeling and only functions to consume security event
descriptions, with no impact outside of its own functionality.

For the benefit of the record, and everyone following along, here is
the diffstat for the recent V4 release:

Documentation/ABI/testing/tsem                | 2420 ++++++++++++++++
Documentation/admin-guide/LSM/index.rst       |    1 +
Documentation/admin-guide/LSM/tsem.rst        | 1680 +++++++++++
.../admin-guide/kernel-parameters.txt         |   29 +
MAINTAINERS                                   |    8 +
include/uapi/linux/lsm.h                      |    1 +
security/Kconfig                              |   11 +-
security/Makefile                             |    1 +
security/security.c                           |    3 +-
security/tsem/Kconfig                         |   36 +
security/tsem/Makefile                        |    6 +
security/tsem/event.c                         | 1846 +++++++++++++
security/tsem/export.c                        |  429 +++
security/tsem/fs.c                            | 2304 ++++++++++++++++
security/tsem/map.c                           | 1536 +++++++++++
security/tsem/model.c                         |  758 +++++
security/tsem/model0.c                        |   21 +
security/tsem/namespace.c                     |  530 ++++
security/tsem/nsmgr.c                         |  255 ++
security/tsem/nsmgr.h                         |   48 +
security/tsem/trust.c                         |  261 ++
security/tsem/tsem.c                          | 2446 +++++++++++++++++
security/tsem/tsem.h                          | 2336 ++++++++++++++++

It should be noted that with version v4, in response to the issues
that Tetsuo has been raising, we implemented the ability to implement
customized LSM event handling through the use of loadable kernel
modules.

Given the code footprint and design, and the Tomoyo discussion and
issues, we believe our approach offers a highly positive benefit/risk
ratio.

> 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

We certainly wouldn't ascribe to be 'git foo' masters but we have used
git a little bit and grep a whole lot.

We believe the following command sheds some light on these statistics:

git log --after=2022 --before=2024 --oneline --no-merges security/security.c |
	egrep -vi "comments|evm|ima|integrity|spelling" | wc -l

Which generates the following value as of the head of the v6.10 tree:

60

The EVM/IMA/integrity integration work is certainly positive, and we
believe was something that you advocated for in coming into the LSM
maintainership role, but its potential negative impacts writ-large are
potentially more significant than an independent LSM.

To extend a bit further with respect to our work.

If one reads the TSEM documentation carefully, one will find that its
functional predicate, from a modeling perspective, is based on tying
security event descriptions to the cryptographic checksums of the
executable that are generating the security events.

By composing from a clean sheet of music you get a simpler and more
self-contained integrity design.  Since a TSEM security model has its
time of measurement based on the unit test of the workload, the
complexity of cryptographic metadata signing (EVM) can be sidestepped
along with a significant component of its performance impact.

So we would posit, once again, that TSEM offers a comparatively low
risk implementation with significant benefit to the Linux security
community.

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

I believe the published record of TSEM clearly does not support this
premise.

For the benefit of everyone following this discussion, we will post
again the links to the four releases:

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

Here is a breakdown of all the review comments received in 20 months:

Casey Schaufler		9
Paul Moore		3
Serge Hallyn		2
Greg Kroah-Hartman	2
Randy Dunlap		1

At the risk of having possibly missed something, we would encourage
everyone else to look at the four link summaries to see if we have
left any review comments unanswered, we don't believe an inspection of
the threads will find that to be the case.

If anyone chooses to clone the TSEM GIT repository, you will find in
the commit summary, references to all of the issues that were raised
and the steps we took to address them.

For the record, we have integrated all of the functional changes
requested by the reviews, most significantly the implementation of
JSON encoding of all security event descriptions, a very positive
review comment from GKH.

Casey's primary concerns have been about the organization of the code,
ie. a single header file with all of the declarations and definitions
for the compilation units in the security/tsem directory.

We reached out to you in advance of the v3 release to find out if you
would like us to re-structure the code to have multiple include files.
You indicated there were far more problems than the code organization,
we asked specifically what those problems would be and received no
response.

The primary technical objection you raised, and to date no one else
has raised this issue, was with the fact that we were exporting the
global PID of an externally modeled process to a trust orchestrator.
This is needed so that the orchestrator can find the process task
structure, in order to set its trust status in its task control
structure before releasing the process for further exection, after the
model evaluation of a security event was completed.

Two of your review comments dealt with this issue.  In your original
response you posited that it was possible to kill a process waiting
for model evaluation and conduct a PID race attack that could
substitute an alternate process to be acted on by the trust
orchestrator.

In response to that concern, we implemented a task authentication
mechanism that requires cryptographic verification of the process by
the trust orchestrator.  We also implemented protections in the
task_kill handler that would allow only tasks with CAP_MAC_ADMIN
status to generate a cross-model/namespace signal that would bring a
modeled task out of its sleep state.

You indicated that authentication was good but insufficient and noted
that an attacker could use the OOM handler to bypass the task_kill
protections.  You posited that pidfd's were how this type of thing
should be done.

We went back and studied the problem in significant detail, including
trust orchestration latency timings and the impact they would have on
the exploitability of a race window.

For the record, here is the lore link to our response that we posted
on 02/19/2024, which to date, we have received no reply to:

https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@enjellic.com/T/#me86004e3cd197046885d371cb70df389beb72c7e

We would hope that anyone in the LSM community, that reads the above,
would conclude that we took time to develop a detailed technical
response to this primary concern you have raised.

A summary for those that don't want to click on the link.

Exploiting the race window would require killing the sleeping process
with the OOM handler, something that we are not sure is even possible,
and then cycling a new process with an identical PID into the PID slot
in approximately 45-90 micro-seconds.  In a worst case scenario, with
a 32 bit PID space, this would require 2 billion forks in the race
window, without the trust orchestrator being re-scheduled, which would
have the effect of terminating the race window.

To extend further, since we are answering a technical criticism.

TSEM's security model predicates on the notion of a trust orchestrator
constraining the behavior of processes in a workload to a set of
cryptographically unique coefficients that represent each security
state the process can enter into.  Those states are dependent not only
on the cryptographic checksum of the executable code that gave rise to
the process but the cryptographic identities of all processes that led
to that process.

If an adversary were to substitute a process that was 'raced' into the
PID slot it would have a different cryptographic identity than the
process it was replacing and would thus generate security events that
were inconsistent with the model being enforced.  This would result in
any further security events by that process being trapped as
untrusted.

An open vulnerability in this model, of course, is if the attacker
could also mount an effective second pre-image attack against the
cryptographic hash function being used to implement the extension sum
that represents the task identity.  To our knowledge, no such attacks
are available against any of the cryptographically secure hash
functions that would be chosen for a TSEM security model.  Such an
attack would represent a major failure in the modern cryptographic
primitives the security industry depends on.

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

We will leave the perceived quality discussion to the previous section
of our response and take on the notion of impact here.

We've stated previously and will state again.  We saw the issue
created by Tetsuo and this Tomoyo incident coming during the COVID
years and began work on addressing what we saw was going to be an
important issue for the Linux security community.

You commented to us in an alternate thread, that you have seen nothing
that Tetsuo has done that would change your mind with respect to
having an LSM being implemented with a loadable module.

If that isn't possible, and there are probably good technical reasons
for that, then we need an LSM that is capable of implementing security
models of one's choosing, using mechanisms that do not necessarily
require having an in-kernel LSM.

That is exactly what TSEM was designed to bring to the Linux security
community.  Which, given the issues this event has raised, would seem
to be a positive contribution with some impact.

Which we also believe justifies more attention than what it has been
able to receive in 20 months.

> paul-moore.com

Hopefully with these clarifications in place we can proceed forward in
a more positive context.

Have a good day.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

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

[Casey Schaufler]

On 10/8/2024 4:14 AM, Dr. Greg wrote:
> ...
>
> Which we also believe justifies more attention than what it has been
> able to receive in 20 months.

You're right. You're also not alone. There are things that you can do
that will help get the review you're looking for. Developers who attend
to the needs and preferences of reviewers get a whole lot more attention
than those who fuss and fume about not getting what they "deserve". My
hopefully constructive recommendations are:

1.	Lead with code. Save the documentation for later.
2.	Incremental implementation. Don't drop the whole mess on the
	reviewers at once. A patch set should be a story, with each patch
	introducing one new element.
3.	Emphasize the similarities with existing implementations. No one
	wants to deal with novel or clever code. If it is familiar, it is
	easy to understand.
4.	Thank your reviewers. Complaints about review latency typically
	increase it.
5.	Do some reviews yourself. That will get in the good graces of other
	reviewers.
6.	Be brief. The biggest single problem with reviewing TSEM has been that
	doing anything takes so long. Multiple paragraph responses to an issue
	don't help. Say it, say it once, say it in small words, and use as
	few of those as possible.

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

[Dr. Greg]

On Tue, Oct 08, 2024 at 11:25:16AM -0700, Casey Schaufler wrote:

Good morning, I hope the week has gone well for everyone.

> On 10/8/2024 4:14 AM, Dr. Greg wrote:
> > ...
> >
> > Which we also believe justifies more attention than what it has been
> > able to receive in 20 months.
> 
> You're right. You're also not alone. There are things that you can do
> that will help get the review you're looking for. Developers who attend
> to the needs and preferences of reviewers get a whole lot more attention
> than those who fuss and fume about not getting what they "deserve". My
> hopefully constructive recommendations are:

We put a significant body of code and engineering time on the table to
try and improve the Linux security ecosystem.  We did this because in
certain circles the value of our approach is understood and there was
a desire to have it more generally available.

We don't believe we 'deserve' anything, review or don't review, it is
completely up to everyone involved.

Believe me when I say we are perfectly capable of supporting our
constituencies without contributing a single line of code or comment
back to the good of the Linux security commons.

Our aggravation in all of this is when statements are made regarding
serious and supposedly well understood flaws in our approach that
'everyone' agrees to be the case.  Statements that are a complete and
utter crock of bullshit meant to simply gaslight the situation that
has gone down.

Hopefully our choice of lingua franca is sufficiently simple and
unsophisticated.

We would, again, encourage everyone to re-read our previous e-mail
where we outlined our concerns over the status of the review that did
occur.

We do respect reviewers, but let's engage in some sense of
intellectual honesty.  This is not a situation of some poor lonely
overworked individual reviewing Linux code in their mother's basement
at night in Gulley, Minnesota while they work at the Cenex Station
during the day.

Paul has publically stated that Microsoft employees him to maintain
the Linux security system because of Microsoft's concern for the long
term health and well being of Linux.  In case anyone doubts this or
missed it, here is the link:

https://lore.kernel.org/linux-security-module/20230608191304.253977-2-paul@paul-moore.com/

Unfortunately our experience seems to challenge Linus' mantra of:

"Code talks, bullshit walks".

Perhaps times have changed for Linux in this new custodial
environment.

> 1.	Lead with code. Save the documentation for later.
> 2.	Incremental implementation. Don't drop the whole mess on the
> 	reviewers at once. A patch set should be a story, with each patch
> 	introducing one new element.
> 3.	Emphasize the similarities with existing implementations. No one
> 	wants to deal with novel or clever code. If it is familiar, it is
> 	easy to understand.
> 4.	Thank your reviewers. Complaints about review latency typically
> 	increase it.
> 5.	Do some reviews yourself. That will get in the good graces of other
> 	reviewers.
> 6.	Be brief. The biggest single problem with reviewing TSEM has been that
> 	doing anything takes so long. Multiple paragraph responses to an issue
> 	don't help. Say it, say it once, say it in small words, and use as
> 	few of those as possible.

We appreciate the insight and recommendations, we will see how and
where all of this ends up getting litigated.

Given the zeal for simplicity embodied in these recommendations, we
will assume that adversaries targeting Linux from a security
perspective will also choose to limit themselves to simple and
unsophisticated means and methods of attack.

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

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

[Casey Schaufler]

On 10/11/2024 10:06 AM, Dr. Greg wrote:
> On Tue, Oct 08, 2024 at 11:25:16AM -0700, Casey Schaufler wrote:
>
> Good morning, I hope the week has gone well for everyone.
>
>> On 10/8/2024 4:14 AM, Dr. Greg wrote:
>>> ...
>>>
>>> Which we also believe justifies more attention than what it has been
>>> able to receive in 20 months.
>> You're right. You're also not alone. There are things that you can do
>> that will help get the review you're looking for. Developers who attend
>> to the needs and preferences of reviewers get a whole lot more attention
>> than those who fuss and fume about not getting what they "deserve". My
>> hopefully constructive recommendations are:
> We put a significant body of code and engineering time on the table to
> try and improve the Linux security ecosystem.  We did this because in
> certain circles the value of our approach is understood and there was
> a desire to have it more generally available.
>
> We don't believe we 'deserve' anything, review or don't review, it is
> completely up to everyone involved.
>
> Believe me when I say we are perfectly capable of supporting our
> constituencies without contributing a single line of code or comment
> back to the good of the Linux security commons.
>
> Our aggravation in all of this is when statements are made regarding
> serious and supposedly well understood flaws in our approach that
> 'everyone' agrees to be the case.  Statements that are a complete and
> utter crock of bullshit meant to simply gaslight the situation that
> has gone down.

Inflammatory claims regarding motivation are not helpful.

> Hopefully our choice of lingua franca is sufficiently simple and
> unsophisticated.

Err, no, it's not. For a complete explanation see "When Jargon Becomes Gibberish":
https://www.youtube.com/watch?v=-7cUnID7vFs

> We would, again, encourage everyone to re-read our previous e-mail
> where we outlined our concerns over the status of the review that did
> occur.
>
> We do respect reviewers, but let's engage in some sense of
> intellectual honesty.  This is not a situation of some poor lonely
> overworked individual reviewing Linux code in their mother's basement
> at night in Gulley, Minnesota while they work at the Cenex Station
> during the day.

HeeHee. There really are hobbyists in situations similar to that.
I've been one of them. To dismiss them as fictional is pretty insulting.

> Paul has publically stated that Microsoft employees him to maintain
> the Linux security system because of Microsoft's concern for the long
> term health and well being of Linux.  In case anyone doubts this or
> missed it, here is the link:

It's pretty rare that a Linux maintainer is paid to do nothing but maintain
Linux code. Developers who are qualified to be kernel maintainers are usually
in demand for other, more directly profitable, projects as well. I can't
speak directly for Paul, but I would be shocked if he gets anywhere close to
half his work time allocated to the maintainer role.

> https://lore.kernel.org/linux-security-module/20230608191304.253977-2-paul@paul-moore.com/
>
> Unfortunately our experience seems to challenge Linus' mantra of:
>
> "Code talks, bullshit walks".
>
> Perhaps times have changed for Linux in this new custodial
> environment.
>
>> 1.	Lead with code. Save the documentation for later.
>> 2.	Incremental implementation. Don't drop the whole mess on the
>> 	reviewers at once. A patch set should be a story, with each patch
>> 	introducing one new element.
>> 3.	Emphasize the similarities with existing implementations. No one
>> 	wants to deal with novel or clever code. If it is familiar, it is
>> 	easy to understand.
>> 4.	Thank your reviewers. Complaints about review latency typically
>> 	increase it.
>> 5.	Do some reviews yourself. That will get in the good graces of other
>> 	reviewers.
>> 6.	Be brief. The biggest single problem with reviewing TSEM has been that
>> 	doing anything takes so long. Multiple paragraph responses to an issue
>> 	don't help. Say it, say it once, say it in small words, and use as
>> 	few of those as possible.
> We appreciate the insight and recommendations, we will see how and
> where all of this ends up getting litigated.
>
> Given the zeal for simplicity embodied in these recommendations, we
> will assume that adversaries targeting Linux from a security
> perspective will also choose to limit themselves to simple and
> unsophisticated means and methods of attack.

Gordian Knot. Alexander. Just saying. 

>
> Have a good weekend.

Likewise.

>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity
>               https://github.com/Quixote-Project
>