On Fri, Feb 7, 2025 at 5:20 AM Dr. Greg [off-list ref] wrote:

On Thu, Feb 06, 2025 at 10:48:57AM -0500, Paul Moore wrote:

quoted

On Wed, Feb 5, 2025 at 7:01???AM Dr. Greg [off-list ref] wrote:

quoted

On Tue, Jan 28, 2025 at 05:23:52PM -0500, Paul Moore wrote:

quoted

I believe the LSM can support both the enforcement of security policy
and the observation of security relevant events on a system.  In fact
most of the existing LSMs do both, at least to some extent.

However, while logging of security events likely needs to be
asynchronous for performance reasons, enforcement of security policy
likely needs to be synchronous to have any reasonable level of
assurance.  You are welcome to propose LSMs which provide
observability functionality that is either sync, async, or some
combination of both (? it would need to make sense to do both ?), but
I'm not currently interested in accepting LSMs that provide
asynchronous enforcement as I don't view that as a "reasonable"
enforcement mechanism.

This is an artificial distinction that will prove limiting to the
security that Linux will be able to deliver in the future.

Based on your response, is it your stated position as Linux security
maintainer, that you consider modern Endpoint Detection and Response
Systems (EDRS) lacking with respect to their ability to implement a
"reasonable" enforcement and assurance mechanism?

quoted

As stated previously: "I'm not currently interested in accepting
LSMs that provide asynchronous enforcement as I don't view that as a
reasonable enforcement mechanism."

You personally don't, the IT and security compliance industry does, it
seems to leave Linux security infrastructure in an interesting
conundrum.

Your concern over the state of the LSM has been previously noted, and
I assure you I've rolled my eyes at each reference since.

For the record, just to be very clear as to what an LSM is allowed to
do under your administration, for our benefit and the benefit of
others ...

I've repeated my position once already, if any current or aspiring LSM
developers are unsure about some aspect of this, they are welcome to
bring their specific concerns to the list and we can discuss them.

quoted

quoted

If this is the case, your philosophy leaves Linux in a position that
is inconsistent with how the industry is choosing to implement
security.

quoted

In this case perhaps TSEM is not well suited for the upstream Linux
kernel and your efforts are better spent downstream, much like the
industry you appear to respect.

Fascinating response from someone given the privilege of
maintainership status of a sub-system in a project whose leadership
preaches the need to always work with and submit to upstream.

Even more fascinating when that individual publically states that he
is employed by the largest technology company in the world because of
that companies desire to promote the health and well being of the
Linux eco-system and community.

I would suggest that your interpretation of my previous comments are a
bit "off" in my opinion, but who am I to argue with a view that sees
my comments as this fascinating!

Jokes aside, to be clear I didn't tell you not to continue to post
newer revisions of TSEM, I simply suggested that based on the choices
you've made in designing and developing TSEM, it may be better suited
to a downstream solution and not the upstream Linux kernel.  However,
perhaps continuing to post a LSM that has not been accepted upstream
due to inherent design decisions is perfectly in keeping with a LSM
that relishes references to Don Quixote.

For the record, we don't respect any industry, we respect the need to
address the challenges associated with how we are currently doing and
thinking about things.

Noted.

-- 
paul-moore.com