Yet another vision of Linux security | Endpoint Security Framework

Stephen Smalley stephen.smalley.work at gmail.com
Thu Jun 20 14:54:28 UTC 2024


On Thu, Jun 20, 2024 at 10:28 AM Stephen Smalley
<stephen.smalley.work at gmail.com> wrote:
>
> 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.

Looking for a list of such hooks, it appears that the BPF LSM is
maintaining a list of sleepable LSM hooks in its sleepable_lsm_hooks
list in kernel/bpf/bpf_lsm.c.



More information about the Linux-security-module-archive mailing list