On Wed, Feb 05, 2025 at 11:58:00AM -0800, Casey Schaufler wrote:

Good morning, I hope the week is progressing well.

I need to climb on an airplane in less than 24 hours to fly to Aspen
to spend some time skiing with the 'beautiful people', so only two
comments.

On 2/5/2025 4:00 AM, Dr. Greg wrote:

quoted

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

Good morning, I hope mid-week is going well for everyone.

After the issue of the functionality of modern cryptographic
primitives, a discussion of the second most important issue Paul
raises.

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.

I'll apologize up front to everyone else for this response, but I
hope it is something you might understand.

A security guard scans a person's access pass. As the computer system that
processes the data is slow, the guard lets the person go through the gate.
An access denial finally comes through. The guard turns and shoots the
intruder. What other choice is available? The intruder may have seen what
should not have been seen. Now the guard has to file a fatal incident report
and slow down everything else while cleaning up the remains.

tl;dr - async access control is just messy.

Stated more precisely, the model is asynchronous behavioral controls
and model response.

It is currently what 100+ billion dollar security companies and their
products are based on.  Which, in an increasingly wide swath of
corporate IT, you are required to implement.

Kernel security maintainers can choose to ignore the issue, doesn't
mean it isn't reality.

We have a very diverse team, members of which have been involved in
international cybersecurity issues that have been in the news.  I've
personally written white papers for the consumption of individuals
that are in the news, as to the socio-technical issues that are behind
why we can't have nice things in cybersecurity.

We believe Linux can improve on this situation.  We at least look on
it as fortunate to have a public record as to why that may not be
possible, if that turns out to be the case.

quoted

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?

You are conflating issues. It isn't the purpose of the system, it is
the mechanism by which it is implemented that is the problem.

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.

Let me cite an example from one of our project advisors.

This individual is a senior principal at a reasonably large technology
products company that depends on Linux almost exclusively to support
its operations.  At any given instant he participates in supervising a
fleet of around 6,000 virtual machines running about 50,000-60,000
containerized workloads.

How can this possibly be a kernel problem?

quoted

All of the Linux deployments are Ansible orchestrated.  The security
deployment consists of disabling SeLinux and installing an EDRS
solution.  Doing the latter checks all the boxes they need for their
corporate security compliance policies.

Without insight regarding what these policies might be it is impossible
to say for sure, but I'll bet a refreshing beverage that they involve
all sorts of application level protocols, and other things the kernel
has no business moderating.

quoted

He, and others, have watched this discussion closely over the last two
years that we have tried to get TSEM reviewed and just recently phoned
me with the following comment:

"I think the problem is that these guys don't understand how security
is being done and the reasons why".

Oh, make no mistake, I (at least) understand how security is being
done these days and find it terrifying. We do in the kernel what can
and should be done in the kernel, but adding general supply chain controls
as an LSM isn't gonna happen in my (admittedly limited) lifetime.

quoted

There is probably not a modern EDRS solution that does not involve
going to the cloud for its decision making enforcement,

Wow. The number and density of application and network protocols
necessary for that to work puts an Austrian pastry to shame. And
you want to put that in the kernel?

quoted

 in most cases
based on Indicators Of Compromise (IOC) trained machine learning
models.  Asynchronous detection, enforcement and remediation is now
standard practice.  In the security industry, a 1 minute response to a
security event is considered the 'gold' standard.

A one minute delay in an openat() call ain't gonna happen.

quoted

For the sake of discussion, lets take a Quixote userspace Trusted
Modeling Agent (TMA) running TSEM based deterministic modeling of a
containerized workload.  As we've discussed previously, demonstrated
average response times are on the order of 170 micro-seconds.

For an event that needs asynchronous enforcement, ie. running in
atomic context, that represents a 3.5 order of magnitude advantage in
response over the industry standard, without the attendant challenges
of going off machine or installing kernel based infrastructure.

What would be the rationale or advantage of denying those that desire
this type of security option, a 3,500 fold increase in security
response times?

Let's take another need for running in userspace, trusted execution
environments.  Support is available in our userspace package for
running a TMA model in either an SGX enclave or in an independent
hypervisor protected execution context, both of which significantly
harden the enforcement implementation against attack by adversaries.

As Linux security maintainer, we assume that you have read Executive
Order 14144 signed on January 16th 2025.

Remember "C2 in '92"? Executive order. Industry invested ~$25 Million
in 1990's dollars in evaluation costs alone. Never enforced. I am not
shaking in my boots.

quoted

  That document specifically
calls out the requirement for the increased use of trusted execution
environments in combination with advancements in endpoint detection.

It shouldn't be a leap in imagination as to the regulatory compliance
advantages associated with hardware attestation that the security
implementation is operational and in a known good enforcement state.

When those technologies have developed some level of maturity and
acceptance they'll be worth considering more seriously.

quoted

Finally, at this point in time, it would seem unwise in the technology
industry, to discount the importance of 'AI', or more correctly
machine learning.  As we've noted before in our discussions, it is
unlikely that we are going to see synchronous LSM enforcement using a
machine learning model trained on potentially trillions of data
observations and indicators.

I'm not discounting AI. I'm questioning it's use in kernel access control
implementations. You cannot ignore the impact of access control on system
performance. Ever.

quoted

The LSM is designed to provide security services to the users of
Linux, not to be a kingdom.

It's never been more than a principality. ;)

quoted

Linux is/was about 'choice' as to how users want to use their
hardware.

Nah, it's about a Finish grad student's side project.

quoted

Artifically limiting the types of security that can be implemented by
the LSM works to the detriment of the security innovation that Linux
can deliver and the Linux user community writ large.

If you can demonstrate a sane implementation of your mechanism we're
all ears. User space policy adjudication isn't sane. It wasn't in the
1980's, it isn't now.

For the official record, a number of your assessments above are
incorrect and do not reflect our implementation or intentions.

It doesn't seem to be a worthwhile expenditure of anyone's time to
discuss technical specifics.

We will remain content to be 'The Ghost of Christmas Yet To Come'.

Best wishes for a productive remainder of the week to everyone.

As always,
Dr. Greg

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