Kernel runtime security instrumentation
Kernel runtime security instrumentation
Posted Sep 7, 2019 22:04 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)In reply to: Kernel runtime security instrumentation by kpsingh
Parent article: Kernel runtime security instrumentation
Then improve it. Translate audit rules into BPF and run them.
> It's got to do with your statement: "If you have a "vulnerable binary" then why the hell it's not deleted?"
How do you recognize that a binary was used for nefarious purposes?
> Environment variables is one use case where one needs to use a signal that audit does not currently provide.
Then extend it, rather than create a completely new system. Is there anything else that is not covered by audit subsystem and that is not a trivial addition?
> I disagree. It's about building defense in depth. The more hoops an attacker has to jump to attack you, the slower and harder it gets for them. Anyways, I am happy to hear if you have a constructive solution. Otherwise, this discussion is simply leading nowhere.
The constructive solution is simple - improve audit subsystem instead of adding more eBPF.
Posted Sep 7, 2019 22:17 UTC (Sat)
by kpsingh (subscriber, #112411)
[Link]
Feel free to go that route and suggest / make improvements to audit. Audit does not meet our other key requirement of having the MAC and signaling (auditing) possible with a single API, which is something that you are not constrained by (based on your comments)
Kernel runtime security instrumentation
> Then improve it. Translate audit rules into BPF and run them.