Yet another vision of Linux security | Endpoint Security Framework
Casey Schaufler
casey at schaufler-ca.com
Thu Jun 20 16:52:36 UTC 2024
On 6/20/2024 6:40 AM, Timur Chernykh wrote:
> Hello!
>
> I'm here for yours' opinions.
>
> The modern Linux, in fact, does not provide convenient options to
> write AV/EDR software
Please don't assume that everyone knows your abbreviations.
Audio Visual / Editable Data Record.
Sure, "everyone knows" what AV/EDR is today. Except that many of
us also know what it was in 2010, 2000, 1990, and 1980. Confusion!
> 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;
"Consistent" is hardly a term you can use to describe Linux security events.
Is binding a socket to a port a security event? Where is the security event
when using io_uring?
> - API to communicate with kernel:
> - To send program-defined events (as audit has);
> - Read events from kernel;
A comprehensive set of events is likely to overwhelm any user space
collector.
> - 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;
Performance concerns (locking, sleeping and a host of others) are
likely to prevent this.
> - Has a portable and flexible events structure which doesn't get
> broken from version to version;
If the kernel's policies, mechanisms and structures were more consistent
you might have a chance at this.
>
> 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).
User-space arbitration of kernel events won't work. It's been tried
repeatedly. I started seeing it in the early 1980's. It always devolved
into a kernel bolt-on, with sub-optimal performance and versatility.
>
> 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.
>
> Best regards,
> Timur Chernykh,
> Lead developer, F.A.C.C.T.
>
More information about the Linux-security-module-archive
mailing list