Skip to content
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

Merged
merged 3 commits into from
Jan 10, 2024

Conversation

vadorovsky
Copy link
Member

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.

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.
@banditopazzo
Copy link
Member

Testing this I noticed something weird.

To reproduce open pulsar in on terminal and in another start an ubuntu container:

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!!
Now exit the container and in the same shell start a different container, for example fedora:

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 ubuntu container instead of fedora.

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 ubuntu container.

You have to restart pulsar to reset from this state

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.
@vadorovsky
Copy link
Member Author

@banditopazzo Thanks for spotting the issue! The last commit should fix it.

@banditopazzo
Copy link
Member

@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.
@banditopazzo banditopazzo merged commit 475b779 into exein-io:main Jan 10, 2024
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants