Tracking events of all descendant processes created by a target process, dealing with cases like orphan processes.

[lclin56]

Motivation

I'm working on a project where it's crucial to monitor system events for a specific process and all of its descendants. The current issue I'm facing is that using proc.sid as a filter condition may not be sufficient for tracking all related descendant processes, especially when a child process creates a new session with setsid, or when dealing with orphaned processes. This gap in functionality is problematic when attempting to track the activity of a particular process tree, as session ID changes and orphan processes can slip through the cracks.

Feature

The feature I would like to see implemented in libsinsp is a mechanism that allows users to define a filtering condition that filters events from all processes except for those that are descendants of a specified target process. This could be accomplished by maintaining a process tree cache at the kernel level, which should be dynamically updated to automatically include new processes spawned by any process in the cache. This ensures that no descendant processes are missed in the tracking, regardless of changes to their session IDs or orphaning of the process.

Alternatives

Alternatives I have considered include manually tracking the process tree in user space, which is not efficient and struggles to maintain real-time accuracy. Relying solely on proc.sid for filtering is also not viable in cases where setsid is invoked. Or are there any fields within the process class that can indicate if the current process originates from my target process?

Additional context

No additional context or screenshots at this point. Should this feature request be accepted, I would be eager to assist with testing and providing feedback.

[Andreagit97]

Ei @lclin56 thank you for reporting this! This seems a legit request!
To understand better what we are talking about, you would like to have a new API in sinsp that allows you to specify a set of comms (command name associated with the process) and receive events only from this set of processes and their descendants, is it true?
If yes, should this API just be called at init time configuring a static set of initial processes or it would be possible to add new processes to the set at runtime?

As a general comment, this feature is certainly interesting but it requires a great amount of work since we have 3 drivers to support (kmod, ebpf, and modern-ebpf) so we need to evaluate if and when we want to schedule it according to the project's priorities.

[lclin56]

Hi @Andreagit97,

Thank you for the prompt response and for considering this feature request!

Yes, you've correctly understood the request. I am indeed looking for an API within that would allow me to specify a set of and track events from these processes and their descendants. This would be extremely valuable for security and monitoring tools that need to focus on the activity of specific processes and their child processes, regardless of their session IDs or if they become orphaned.sinspcomms

Regarding the API's behavior:
I'm not entirely certain about this aspect either. If the API is invoked only at initialization, we would essentially have separate customers tracking the target processes and their descendants, which could provide good decoupling. On the other hand, if we could dynamically call this API to add or remove target processes of interest, could this lead to better performance?

I understand the complexity and the workload required to implement this feature across the different drivers. Considering the project's priorities, could we maybe discuss a phased approach? For example, we could start with support for the most widely-used driver and gradually extend functionality to the others. Also, I'm willing to contribute to the development and testing of this feature.

Please let me know how I can assist further and whether there are any workarounds I could use in the meantime.

[Andreagit97]

On the other hand, if we could dynamically call this API to add or remove target processes of interest, could this lead to better performance?

What probably changes here is the complexity of the solution, with a runtime customization we need to handle more cases and more complexity for sure. Regarding the performance, you can have the possibility to remove some processes that you don't want to track anymore at runtime, so yes you could have a gain, but also a decrease if you add more processes to track during the execution... By the way, I asked it to understand if you had some precise use cases for implementing a more dynamic approach

I understand the complexity and the workload required to implement this feature across the different drivers. Considering the project's priorities, could we maybe discuss a phased approach? For example, we could start with support for the most widely-used driver and gradually extend functionality to the others. Also, I'm willing to contribute to the development and testing of this feature.

It could be an idea, just out of curiosity, which driver are you using?

[lclin56]

Regarding the idea of dynamically calling this API, I have considered it. When I am analyzing an unknown program, I need to track the descendants of the process started by the program. Calling this API during initialization can meet the requirements of this scenario. But it may be possible that the program has process injection or remote execution behavior. In this case, we need to add related processes (not just descendants) to the tracking target. Regarding the other question, the driver I am currently using is kmod, because it supports a broader range of kernel versions and can be used in many terminal environments.

[Andreagit97]

Thank you for the precious feedback! We will evaluate the feature request!

[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

[Andreagit97]

/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

[Andreagit97]

/remove-lifecycle stale