Message-ID: <e8ec2704-90bf-4e67-9e90-eb206e6d08c0@schaufler-ca.com>
Date: Wed, 5 Feb 2025 11:58:00 -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, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v4 2/14] Add TSEM specific documentation.

On 2/5/2025 4:00 AM, Dr. Greg wrote:
> 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.
>
>> 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.

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

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

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

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

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

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

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

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

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

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

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

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

Powered by blists - more mailing lists