|
|
Subscribe / Log in / New account

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

> We are doing performance comparisons and it's not.
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.


to post comments

Kernel runtime security instrumentation

Posted Sep 7, 2019 22:17 UTC (Sat) by kpsingh (subscriber, #112411) [Link]

> We are doing performance comparisons and it's not.
> Then improve it. Translate audit rules into BPF and run them.

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)


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds