-
Notifications
You must be signed in to change notification settings - Fork 431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
argument filtering in eBPF #1536
Comments
How is this different than current argument based fillers? |
The filtering here as at event level. The ones we already have are per user/process etc. |
we have filters at the event level as well: e.g |
The difference is in where you do the filtering. |
we could move filtering logics from user to kernel (keeping the same frontend like |
@NDStrahilevitz this is one issue you should keep track of (for the major 'filtering improvement' effort you're handling). |
Hello, can I be assigned to this ? And would a hashmap to give the required information to the probes do the trick ? |
Thanks @cdelzotti, actually, this is something I already started to tackle and have plans for. |
Closing in favor of #4430 |
We would like to have the option to inject filters to eBPF events. For example,
security_open_file
event is fired many times, and most of it is non-suspicious paths. The idea here would be to limit the order of magnitude the event is triggered, by inserting for example a filter to the event. For a real case example think about that:security_open_file
will be sent to users-pace for further processing, only if the file path is/etc/password
.The text was updated successfully, but these errors were encountered: