linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. Greg" <greg@enjellic.com>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, jmorris@namei.org
Subject: Re: [PATCH v4 2/14] Add TSEM specific documentation.
Date: Fri, 7 Feb 2025 04:20:24 -0600	[thread overview]
Message-ID: <20250207102024.GA6415@wind.enjellic.com> (raw)
In-Reply-To: <CAHC9VhRq0PrH=0n6okkvfed=8QQOfv-ERA60NNWvLXetgrB_2w@mail.gmail.com>

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

Good morning to everyone.

> On Wed, Feb 5, 2025 at 7:01???AM Dr. Greg <greg@enjellic.com> wrote:
> > On Tue, Jan 28, 2025 at 05:23:52PM -0500, Paul Moore wrote:
> >
> > > 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?

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

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:

An LSM asynchronously streams an encoding of every security event that
occurs into something in userspace, somewhere, that interprets those
events.  Is userspace allowed to directly signal the operating system
if it detects an anomaly in one of those events or a pattern of events
and at what resolution level can the signalling occur?

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

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

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.

> paul-moore.com

Our apologies to everyone for being a voice crying out in the
wilderness.

As always,
Dr. Greg

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

  reply	other threads:[~2025-02-07 10:20 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-26 10:37 [PATCH v4 00/14] Implement Trusted Security Event Modeling Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 01/14] Update MAINTAINERS file Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 02/14] Add TSEM specific documentation Greg Wettstein
2025-01-14  1:29   ` [PATCH v4 2/14] " Paul Moore
2025-01-17  4:47     ` Dr. Greg
2025-01-17 18:10       ` Casey Schaufler
2025-01-18 19:03         ` Dr. Greg
2025-01-21 18:09           ` Casey Schaufler
2025-01-26 18:40             ` Dr. Greg
2025-01-28 22:23       ` Paul Moore
2025-01-31 17:11         ` Dr. Greg
2025-02-25 12:01         ` Dr. Greg
2025-02-25 15:48           ` Casey Schaufler
2025-02-27 12:12             ` Dr. Greg
2025-02-27 16:47               ` Casey Schaufler
2025-03-03 10:14                 ` Dr. Greg
2025-03-03 16:23                   ` Casey Schaufler
2025-02-05 12:00     ` Dr. Greg
2025-02-05 19:58       ` Casey Schaufler
2025-02-06 12:45         ` Dr. Greg
2025-02-06 15:48       ` Paul Moore
2025-02-07 10:20         ` Dr. Greg [this message]
2025-02-07 17:42           ` Casey Schaufler
2025-02-08  0:29           ` Paul Moore
2025-02-17 12:53             ` Dr. Greg
2025-02-17 23:09               ` Paul Moore
2024-08-26 10:37 ` [PATCH v4 03/14] TSEM global declarations Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 04/14] Add primary TSEM implementation file Greg Wettstein
2024-08-26 15:53   ` Casey Schaufler
2024-08-27 10:52     ` Dr. Greg
2024-08-27 17:51       ` Casey Schaufler
2024-08-26 10:37 ` [PATCH v4 05/14] Add root domain trust implementation Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 06/14] Implement TSEM control plane Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 07/14] Add namespace implementation Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 08/14] Add security event description export facility Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 09/14] Add event processing implementation Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 10/14] Implement security event mapping Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 11/14] Implement the internal Trusted Modeling Agent Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 12/14] Implement configuration and methods for default model Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 13/14] Implement infrastructure for loadable security models Greg Wettstein
2024-08-26 10:37 ` [PATCH v4 14/14] Activate the configuration and build of the TSEM LSM Greg Wettstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250207102024.GA6415@wind.enjellic.com \
    --to=greg@enjellic.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).