Far much easier to suppress kernel/driver log of kernel addresses and deny access to /dev/kmem, et. al.

Leaving eBPF access open demonstratively has made way for file-less persistent malware to linger on unwantedly.

A real cybersecurity specialist would only allow eBPF access on host OS if no network access can be made to the host OS (and its ok for guest VMs to have eBPF).

An Uber cybersecurity goon, however, would compile out the eBPF JIT access from the Linux kernel (or use BSD-variant, instead).

Hmmm, there's interesting possibilities here to build a kind of application-IDS.

Execute and monitor a program/app while running its full test suite, to generate a model of all the stuff that program normally does.

Then monitor it in prod and if it starts behaving weirdly, kill it (and investigate).

I wonder how well the models will hold up against attacks that merely exercise normal application functions in unusual ways?

The github link if you just want to look at the code: https://github.com/evilsocket/ebpf-process-anomaly-detection

Looking at rate of change is a quite efficient way to go about this. Kudos to the author.

This sounds little bit like Process Homeostasis[0].

0: https://people.scs.carleton.ca/~mvvelzen/pH/pH.html