lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHC9VhRq0PrH=0n6okkvfed=8QQOfv-ERA60NNWvLXetgrB_2w@mail.gmail.com>
Date: Thu, 6 Feb 2025 10:48:57 -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 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."

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

-- 
paul-moore.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ