Message-ID: <CAHC9VhQRz2ofH_HgUGw=voNyP8nYKQZwJGg_wb+hgGfXHex00Q@mail.gmail.com>
Date: Mon, 17 Feb 2025 18:09:06 -0500
From: Paul Moore <paul@...l-moore.com>
To: "Dr. Greg" <greg@...ellic.com>
Cc: linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, 
	jmorris@...ei.org
Subject: Re: [PATCH v4 2/14] Add TSEM specific documentation.

On Mon, Feb 17, 2025 at 7:53 AM Dr. Greg <greg@...ellic.com> wrote:
> On Fri, Feb 07, 2025 at 07:29:58PM -0500, Paul Moore wrote:
> > On Fri, Feb 7, 2025 at 5:20???AM Dr. Greg <greg@...ellic.com> wrote:
> > > On Thu, Feb 06, 2025 at 10:48:57AM -0500, Paul Moore wrote:
> > > > On Wed, Feb 5, 2025 at 7:01???AM Dr. Greg <greg@...ellic.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.
>
> > 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.
>
> Addressed at the end of this e-mail.
>
> You can also see our reply to James Morris and the announcement of the
> Linux Security Summit in Denver this summer.

I did.  As Casey already mentioned, you are free to submit a proposal.
I believe most of the program committee will remember you from your
previous presentation.

> > > 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.
>
> For the record, we did bring a specific concern to the list for
> discussion, you removed the question and example we raised from your
> reply.

I routinely trim replies to improve readability, especially in the
case of large emails, and since mailing lists are archived no data is
lost.  As far as answering questions regarding hypothetical LSMs, I
see no reason to do so given the nature of your on-list comments of
late.  I've provided feedback on the specifics of the TSEM approach as
well as general feedback on async enforcement and that will have to be
sufficient for now.

-- 
paul-moore.com

Powered by blists - more mailing lists