Re: Yet another vision of Linux security | Endpoint Security Framework

["Dr. Greg" <greg@enjellic.com>]

On Thu, Jun 20, 2024 at 11:39:43PM +0900, Tetsuo Handa wrote:

Good morning, I hope the week is starting well for everyone.

> On 2024/06/20 22:40, Timur Chernykh wrote:
> > Questions I'm interested in:
> > How does the community feel about this idea? Is it a viable concept?
> > If all is OK, what should I, as developer, do further? How much kernel
> > code outside the LSM module may be modified to keep further merge
> > acceptable? (currently not all LSM hooks meet to intercept all needed
> > data).
> > 
> > The general purpose is to make AV/EDR software development easier,
> > more convinient, and stable for Linux-based operating systems. This
> > PoC (as far as technology idea) is inspired by MacOS Endpoint Security
> > based on MAC policy.

> I agree that security hooks for AV/EDR software are missing in
> Linux.

The issue isn't an insufficient number of security hooks, the issue is
that the detection of anomalous behavior is not being framed properly.

This is a modeling problem.  The challenge is that it is a modeling
problem over a range of potential model types, each with its own set
of advantages and disadvantages.  So the best thing that can be done
is to expose the basis set of information that the Linux development
community has indicated as relevant to the security posture of the
operating system.

That basis set is currently the LSM hooks.  Given the amount of
information that can be surfaced by these hooks, the security industry
hasn't even scratched the surface with respect to the available
detection limits.

> My experience says that customers cannot afford managing
> allowlist-based access control mechanisms (such as SELinux and
> AppArmor) and they instead choose AV/EDR software for their systems.

This issue, which may be an unpopular concept in some corners of the
this list, is true.  The market has spoken, for both technical and
political reasons, the future is going to involve host based modeling
and detection of unwanted platform or workload behaviors.

There are a myriad of technical reasons for this, the political reason
though is pretty sample, paying a vendor to be responsible for
detecting security intrusions allows companies, to at least
ostensibly, transfer the liability from themselves to another entity.

It is basically a manifestation of the long standing technology meme
of: "No one ever got fired for buying IBM".

> The LSM framework (which is using linked list for registering multiple
> LSM modules) is about to be replaced with static calls (which reduces
> overhead, at the cost of restricting at build time LSM modules which can
> be registered). Use of static calls might make it possible to insert more
> hooks into the Linux kernel because the overhead becomes negligible, but
> kernel code used by AV/EDR software cannot be built into distributor
> kernels due to support problem. Therefore, without ability to load
> unlimited number of LSM modules after boot, AV/EDR software won't be
> benefited with static calls. Such limitation will lead people to invent
> a new set of security hooks (or resort to unofficial hacks such as
> rewriting readonly data structure) rather than trying to utilize LSM
> framework.

The commentary above would thus suggest that the problem is not one of
an insufficient number of LSM hooks but rather the amount of
flexibility with respect to interpreting the existing hooks.

What we would suggest is needed is 2-fold.

First, there is not a need for more LSM's but rather an LSM that has
more flexibility with respect to the type of responses that can be
implemented for the existing hooks.  The BPF LSM is a partial step in
that direction, but there are challenges that you have previously
documented, with respect to what can be accomplished.

Secondly, we would posit that there is more interest from the security
industry in getting the information provided by the existing hooks out
of the kernel for analysis rather than implementing the classic
immediate response model of current mandatory access control systems.

We would further suggest that even casual observation of the security
industry would indicate, that like many other technology venues, it is
now completely enamored with the notion of the application of
AI/machine learning to it mission.  That is not going to happen inside
of the kernel, the question will be providing an optimized framework
for making this happen.

At the risk of being accussed of 'hijacking' a thread, we would posit
that we are addressing both issues with our TSEM implementation,
particularly in the V4 release that is right around the corner.

> I prefer getting kernel code used by AV/EDR software reviewed (and get
> their code tested by fuzzers), by allowing AV/EDR software developers
> to submit their kernel code for upstream.

We would also suggest that it is unlikely that security vendors are
going to be willing to submit much, if any, of their 'secret sauce'
for inclusion in the kernel.  Alexey Starovoitov aluded to this at his
BPF presentation at the European Security Summit.

At least on Linux, the current endpoint security agent architecture
that the industry is grappling with is a functional and security
nightmare waiting to happen.

The most positive security contributions will surround reducing the
security footprint and privilege level that the vendors need in order
to accomplish their objectives, along with increasing the simplicity
of access to the vast amount of information that is available from the
existing hooks/handlers.

Have a good week.

As always,
Dr. Greg

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