Skip events for process and thread with PID in kernel

[albe19029]

When using scap library is is not possible to skip events for process, who started monitoring. There are a logic with suppressor, but it is too complicated, as if for some reason fork(clone) events will be lost, there are no 100% logic to not pass event to next user processing.

But checking pid in kernel is much simple. Maybe it is possible to add such a filter in kernel to simplify skipping events in user space and make lower cpu and ring buffer using.

[FedeDP]

Hi! Thanks for opening this feat request!

We already have a proposal opened for this: #1867, feel free to reach over there and add your suggestions/feedback over there :)

But checking pid in kernel is much simple.

That is of course simple, but how effective would that be? I mean, aside from eg: pid 0, how many other pids are constant in the system?

[albe19029]

In my ticket I only mean to skip events for the process who called scap_open as in our case we don't need information about ourselves.

[albe19029]

It is normal that 2 sysdig processes will see each other. But we need a way to skip events for process for himself.

[albe19029]

It is normal also to filter events by process comm name. In this case sysdig will not see events on other sysdig. But it is normal also.

[albe19029]

As I can see for kmod driver we have consumer_id (task_struct) where we can get PID. And when pushing events to consumer ring buffer it can be checked that PIDs are equal, and skip if configured. For bpf - is is harder, as there are no ppm_open - open device method where thread information is stored, and ppm_close where it can be automatically released.

[albe19029]

For bpf as I understand map is per load.

struct bpf_map_def SEC("maps") exclude_comm = {
.type = BPF_MAP_TYPE_ARRAY,
.key_size = sizeof(u32),
.value_size = 16,
.max_entries = 1,
};

So map like this can be loaded on scap_open and they be used to filter events for this process.

[Andreagit97]

Ei @albe19029 thank you for the feature request! This is something we are discussing in this period, and yes, one of the ideas is to move the suppression logic to the kernel space since it would allow us to drop the event before sending it to userspace. There is no ETA for this ATM but it is on our radar!

[albe19029]

Is there are something we can help in this process? As skipping process which run scap_open reduce a lot of code and CPU for us.
Thanks a lot.

[Andreagit97]

I think the main blocker here is that none of us currently have enough capacity to try an implementation. If you feel enough confident you can try to propose an implementation of this :)!

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[albe19029]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale