Additional filtering #284
Replies: 2 comments
-
I think in terms of priority, it's more important to add filters for uts and mount ns (and potentially cgroup). I don't see many use cases for uid, and process name is already doable using pid filter. |
Beta Was this translation helpful? Give feedback.
-
Relevant discussion in #312 |
Beta Was this translation helpful? Give feedback.
-
Generalizing the filtering idea from #29 , I think we should discuss how we want filtering in Tracee to be like.
Today we already enable the user to filter by event and by pid.
I think the following filters should be added as well (context filters):
In addition to these, we can support filtering by events arguments.
Thinking about implementation, these filters can be implemented as maps shared between the user and bpf program.
Doing the filtering in the kernel (where possible) is more efficient, as we then save the need to send an irrelevant event to the user space.
Each filter type can have its own map (e.g. uid_filter_map), where the key is what we want to filter by.
For numerical values (e.g. uid), the value of the map will be one of '0', '1', '2', which will represent lower than, equal, or greater than (the values will be enums).
For string values (e.g. utsname), the value of the map will be '0' or '1' for equal and not equal. We can also have '2' for prefix.
We also should take into account that loops and instruction count is limited in eBPF, so the number of filters should also be limited.
Regarding the UX, we can do something like the following for context filters:
for numberical values: --user id, --user <id, --user >id
for string values: --utsname somename, --utsname !somename
WDYT?
For arguments filters, we should be able to let the user specify the event and argument name of interest - ideas?
Beta Was this translation helpful? Give feedback.
All reactions