With many of these bypasses, the usage of eBPF is incidental. TOCTOU issues, Seccomp's limitations, process hollowing (what the author describes as an execution bypass) etc. are all real problems, but they were real problems before eBPF was involved.
The current state of the art is bpflsm (KRSI). It addresses many of these issues, not by doing anything special* with eBPF, but just by being an LSM: it's mandatory access control, the security hooks are on the path for new system calls and it's hard to get rid of if you're an attacker.
There are still problems, of course: if you never ask the kernel for anything (e.g. call execve), then the eBPF instrumentation never runs, rather obviously. There are other ways to check for process hollowing, though - off the top of my head, I'd look for page protections being set to write+execute. An attacker can saturate whatever event reporting mechanism you have, though that would be reportable via a second channel and the new BPF ring buffers have considerably higher throughput.
I had to check the date the article came out, because it feels like a description of the state of the art three years ago, not today.
> It addresses many of these issues, not by doing anything special* with eBPF, but just by being an LSM: it's mandatory access control, the security hooks are on the path for new system calls and it's hard to get rid of if you're an attacker.
Was there meant to be a footnote following "special*"?
Ah, yeah! There have been some new features in eBPF over the past few years, without which the bpflsm would be a lot less useful. None of this was done /specifically/ for the LSM, AFAIK, but all of it is relatively new and I think the LSM was among the first places where these things were deployed:
1) The BPF ring buffer. Previously, we had to use the perf ring buffer to get data out of the kernel, which was hard to use efficiently.
2) BTF enabled BPF programs to read kernel data structures without having to have specialized helpers defined for everything.
3) A lot of improvements to BPF itself, more powerful verifier, atomics support, etc. all enabled more useful BPF programs. AFAIK none of this had to do specifically with the LSM, but still gradually built up BPF as a viable option.
The current state of the art is bpflsm (KRSI). It addresses many of these issues, not by doing anything special* with eBPF, but just by being an LSM: it's mandatory access control, the security hooks are on the path for new system calls and it's hard to get rid of if you're an attacker.
There are still problems, of course: if you never ask the kernel for anything (e.g. call execve), then the eBPF instrumentation never runs, rather obviously. There are other ways to check for process hollowing, though - off the top of my head, I'd look for page protections being set to write+execute. An attacker can saturate whatever event reporting mechanism you have, though that would be reportable via a second channel and the new BPF ring buffers have considerably higher throughput.
I had to check the date the article came out, because it feels like a description of the state of the art three years ago, not today.
Source: I worked on this stuff for 5 years.