Yet another vision of Linux security | Endpoint Security Framework

[Stephen Smalley]

On Thu, Jun 20, 2024 at 9:40 AM Timur Chernykh <tim.cherry.co at gmail.com> wrote:
>
> Hello!
>
> I'm here for yours' opinions.
>
> The modern Linux, in fact, does not provide convenient options to
> write AV/EDR software with real-time system events analysis as far as
> unified system security events. For now we have only inconsistent
> self-made events from eBPF, audit, fanotify, etc. eBPF itself is a
> cool technology, but even CO-RE sometimes works as not expected or
> gets broken, for example:
> https://github.com/aquasecurity/tracee/pull/3769/files. This hack (one
> of a huge amount of the same hacks) looks a bit "crutchy".
>
> As an EDR developer, I have an idea how to fix this situation, using a
> unified endpoint security framework (ESF) placed in the kernel. Its
> must:
> - Provide unified and consistent security events;
> - API to communicate with kernel:
>  - To send program-defined events (as audit has);
>  - Read events from kernel;
> - Trusted agents delivery mechanisms (signing like kernel modules);
> - Has a possibility to control what happens on system e.g block some
> file operations, binary executions and so on;
> - Has a portable and flexible events structure which doesn't get
> broken from version to version;
>
> For now I have PoC, which describes the concept in more detail:
> GH mirror: https://github.com/Linux-Endpoint-Security-Framework/linux.
> It contains all listed above points (maybe except portable event
> structures)
>
> There are an examples with:
> - Security agent:
> https://github.com/Linux-Endpoint-Security-Framework/linux/blob/esf/main/samples/esf/agent.c
> - API: https://github.com/Linux-Endpoint-Security-Framework/linux/blob/esf/main/include/uapi/linux/esf/ctl.h
> - Event structures and types:
> https://github.com/Linux-Endpoint-Security-Framework/linux/blob/esf/main/include/uapi/linux/esf/defs.h
> - Main ESF source code:
> https://github.com/Linux-Endpoint-Security-Framework/linux/tree/esf/main/security/esf
>
> 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 could be wrong, but I thought that supporting such solutions was one
of the reasons that fanotify was introduced, and that some combination
of LSM + fanotify + audit could fulfill most if not all of the
requirements. Can you explain which ones can't be met using those
today?

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