-
Notifications
You must be signed in to change notification settings - Fork 55
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
fix: Handle containers which were running before Pulsar #236
fix: Handle containers which were running before Pulsar #236
Conversation
Always check whether a detected process belongs to a container-related cgroup. This way we ensure that we are adding container info even when the container was created before Pulsar was launched.
Testing this I noticed something weird. To reproduce open docker run --rm -it ubuntu Then in the container run for example: cat /etc/shadow to trigger a rule and you get something like: [2024-01-08T11:28:09Z THREAT ubuntu sha256:174c8c134b2a94b5bb0b37d9a2b6ba0663d82d23ebf62bd51f74a2fd457333da /usr/bin/cat (15893)] [rules-engine - Read sensitive file] File Opened { filename: /etc/shadow, flags:(O_RDONLY) } The container is detected, cool!! docker run --rm -it fedora and same as before trigger the rule with the previous command. The output is: [2024-01-08T11:34:44Z THREAT ubuntu sha256:174c8c134b2a94b5bb0b37d9a2b6ba0663d82d23ebf62bd51f74a2fd457333da /usr/bin/cat (16357)] [rules-engine - Read sensitive file] File Opened { filename: /etc/shadow, flags:(O_RDONLY) } So the process is detected as running in the And also if you exit the container and in your host machine try to trigger a rule, even the host process is detected as running in the You have to restart |
Before this change, we were storing a map of namespaces and corresponding container info, but that didn't work - namespaces used by one container might be reused by a next container later. This change drops that solution and fetches the container info always.
@banditopazzo Thanks for spotting the issue! The last commit should fix it. |
I confirm that now it's working correctly. Before merge can we get rid of these warnings/errors on pid 0 namespaces? [2024-01-08T16:45:37Z WARN bpf_filtering::process_tree] Failed to determine uts namespace for process Pid(0): failed to get the uts namespace for process 0
[2024-01-08T16:45:37Z WARN bpf_filtering::process_tree] Failed to determine ipc namespace for process Pid(0): failed to get the ipc namespace for process 0
[2024-01-08T16:45:37Z WARN bpf_filtering::process_tree] Failed to determine mnt namespace for process Pid(0): failed to get the mnt namespace for process 0
[2024-01-08T16:45:37Z WARN bpf_filtering::process_tree] Failed to determine net namespace for process Pid(0): failed to get the net namespace for process 0
[2024-01-08T16:45:37Z WARN bpf_filtering::process_tree] Failed to determine pid namespace for process Pid(0): failed to get the pid namespace for process 0
[2024-01-08T16:45:37Z WARN bpf_filtering::process_tree] Failed to determine time namespace for process Pid(0): failed to get the time namespace for process 0
[2024-01-08T16:45:37Z WARN bpf_filtering::process_tree] Failed to determine cgroup namespace for process Pid(0): failed to get the cgroup namespace for process 0
[2024-01-08T16:45:37Z ERROR pulsar_core::pdk::process_tracker] reading link failed /proc/0/cgroup
[2024-01-08T16:45:37Z ERROR pulsar_core::pdk::process_tracker] reading link failed /proc/0/cgroup |
The scheduler/idle task is not our object of interes and it has no cgroups or namespaces, it also never can belong to any container. Just ignore it.
Always check whether a detected process belongs to a container-related cgroup. This way we ensure that we are adding container info even when the container was created before Pulsar was launched.