Message-ID: <a17e67db-c983-4955-825d-167855601bb1@schaufler-ca.com>
Date: Fri, 7 Feb 2025 09:42:54 -0800
From: Casey Schaufler <casey@...aufler-ca.com>
To: "Dr. Greg" <greg@...ellic.com>, Paul Moore <paul@...l-moore.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 2/7/2025 2:20 AM, Dr. Greg wrote:
> 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@...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.
>
> 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?

Not to throw a wet blanket on your argument, but you can do just that
with a combination of the audit trail and Smack. Well, mostly. You can't
retroactively deny an access, but you can change the Smack label on a
file or change the access rules as desired. What you can't do is detain
an event while user space is queried about the decision. That is, I
believe, the fundamental problem with your approach.

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

"Work with" sometimes means you don't get everything you thought you
wanted in the way you wanted it. Refer to the work on LSM stacking,
which looks very different now than it did when I started on it in 2010.

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

You aren't crying anything new. It's not easy to address all of the
issues necessary to make a chunk of code acceptable to the Linux
kernel. I doesn't help that you're crying in a language in which much
of your audience is not fluent.

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

Powered by blists - more mailing lists