tracee
tracee copied to clipboard
aquasecurity
argument filtering in eBPF
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.
Lets use this as a major issue for the eBPF filtering (roadmap)
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 --trace openat.pathname=/tmp*
The difference is in where you do the filtering. The filters you refer to happen in userspace, meaning that all the events have to go through the perf buffer, thus might cause lost events in high volumes. Filtering in the bpf code will avoid such lost events by not sending irrelevant events to userspace.
we could move filtering logics from user to kernel (keeping the same frontend like --trace openat.pathname=/tmp*). The question is if we can do so with potentially all the events we have.
@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 ?
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. It is probably not the best issue to start with in tracee anyway, as it will also require partitioning the bpf programs using tail calls due to reaching instructions limit.