Yet another vision of Linux security | Endpoint Security Framework

[Timur Chernykh]

> I could be wrong, but I thought that supporting such solutions was one
> of the reasons that fanotify was introduced

You're right. Fanotify was invented to solve AV developers' problems,
but it gives only a filesystem monitor with, in my opinion, weak
instrumentary, when the modern EDR solutions do much more than just FS
control: firewall, fs protection, process monitoring, vulnerabilities
scanning, container security and so on.

> Can you explain which ones can't be met using those
> today?

Audit + fanotify doesn't give you control over the whole system, which
good AV/EDR should provide as a feature. For example, now you can not
"pause" the process execution and then "allow" it after scanning, like
Windows defender. You even cannot deny binary file or script
execution, like in my PoC here:
https://github.com/Linux-Endpoint-Security-Framework/linux/blob/esf/main/samples/esf/agent.c#L543

Moreover, you can retrieve consistent information from just fanotify
and audit and correlate it because:
- They have a different format of events;
- They aren't synchronized with each other at all;
- Audit is not a reliable source of information, it has some sort of
events that differs or may be or may not be from system to system.

Of course, this is just "another programmers' task", but it could be
better if Linux provides it all from the box, like MacOS.

In my vision there should be only *one* source of security events for
the whole system. All events should be consistent and sequenced.

> Note that a number of the LSM hooks are called from interrupt or while
> holding locks and thus cannot sleep/block.

Yes, I know, thank you. This doesn't seem to be a big problem.

> I don't know the reason, but I think that that is because LSM framework
> did not officially support loading LSM modules after boot, and LSM hooks
> did not receive enough arguments needed by AV/EDR software.

Yep, I'm talking about moving all security logic to userspace, by
allowing some security agent(s) (like EDR or AV) to interact with
restricted API.
In this concept kernel just gives a guarantee of well-written code to
developers and delegates userspace protection to EDR/AV vendors. It's
like a loadable LSM module, but in userspace and not eBPF :)

I believe that there's no need in loadable LSM at all, just a security
agent, which communicates with the kernel. Therefore some of "hooks"
might not be LSM, it can be integrated in the kernel as part of
technology, as it is done with audit.

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

Of course, it's an obvious thing, but at this step I haven't set up
any fuzzers or checks. It'll definitely be done in case this idea get
approve from community and I'll continue working on this PoC like on
new technology.