Kernel runtime security instrumentation
Kernel runtime security instrumentation
Posted Sep 7, 2019 20:26 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)In reply to: Kernel runtime security instrumentation by kpsingh
Parent article: Kernel runtime security instrumentation
And so will be eBPF. There's also a low-hanging fruit of using BPF to JIT-compile the audit rules.
> Patching / deleting a binary on a really huge number of servers cannot be done in seconds.
What does it have to do with audit slowness?
> Can you audit environment variables with audit? No you cannot!
> What do you need to do to add support? Change a lot of stuff, the policy language, auditd, parsers etc.
Do environment variables actually pose a significant threat to warrant a new full-blown, user-controlled arbitrary code injection facility on the critical paths? Can it itself be abused to create livelocks/deadlocks? Can an adversary use it to frustrate efforts to recover? ....
> The development cycle for adding a new signal and then some new policy based on the signal, e.g. a permission error if you set the same environment variable twice, touches many components and this is an attempt to fix that.
I contend that none of this is even needed, as it's going to be useless and trivial to bypass.
Posted Sep 7, 2019 20:52 UTC (Sat)
by kpsingh (subscriber, #112411)
[Link] (2 responses)
>> Patching / deleting a binary on a really huge number of servers cannot be done in seconds.
It's got to do with your statement: "If you have a "vulnerable binary" then why the hell it's not deleted?"
> Do environment variables actually pose a significant threat to warrant a new full-blown, user-controlled arbitrary code injection facility on the critical paths? Can it itself be abused to create livelocks/deadlocks? Can an adversary use it to frustrate efforts to recover? ....
Environment variables is one use case where one needs to use a signal that audit does not currently provide. We are **not** talking about unprivileged eBPF here, it needs CAP_SYS_ADMIN and CAP_MAC_ADMIN. If privileged users want to shoot themselves in their feet, they have plenty other opportunities.
> The development cycle for adding a new signal and then some new policy based on the signal, e.g. a permission error if you set the same environment variable twice, touches many components and this is an attempt to fix that.
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.
Posted Sep 7, 2019 22:04 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> It's got to do with your statement: "If you have a "vulnerable binary" then why the hell it's not deleted?"
> Environment variables is one use case where one needs to use a signal that audit does not currently provide.
> 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.
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
^^^^^^^^^^^^^^^^^^^
We are doing performance comparisons and it's not.
> What does it have to do with audit slowness?
> I contend that none of this is even needed, as it's going to be useless and trivial to bypass.
Kernel runtime security instrumentation
Then improve it. Translate audit rules into BPF and run them.
How do you recognize that a binary was used for nefarious purposes?
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?
The constructive solution is simple - improve audit subsystem instead of adding more eBPF.
Kernel runtime security instrumentation
> Then improve it. Translate audit rules into BPF and run them.