Feature to only track container processes

[JuxhinDB]

Feature

Since most use-cases are based on container applications, Pulsar should be able to filter and to track only container processes. Pulsar is already able to monitor and track container applications. It would be nice to filter them based on the container ID.

Possible solution

Previous Pulsar versions attempted to do this using cgroups. Also Tracee uses cgroups (https://github.com/aquasecurity/tracee/issues/255).

---

Original issue author: @hdtrinh

[hnidoaht-101]

I'm on it. Starting to get used to going through the source code and playing around based on suggestions, maybe I'm starting a little slow for this GFI but once it's done I'm quite confident I'll be fast more for the next features.

[JuxhinDB]

That's great to hear -- you're more than welcome to open up a PR and we'll gladly help review it for you!

[hnidoaht-101]

That's great to hear -- you're more than welcome to open up a PR and we'll gladly help review it for you!

yeah sure, definitely will create PR once I have something to show / get stuck 😛

[MatteoNardi]

Since most use-cases are based on container applications, Pulsar should be able to filter and to track only container processes. Pulsar is already able to monitor and track container applications. It would be nice to filter them based on the container ID.

Containers are implemented using namespaces (for separating the views of the system) and cgroups (for limiting resource usage). Each container runtime has its own peculiarities, which makes a general and user-friendly solution quite hard to implement. For example, with Docker, the simplest way to filter by Docker container ID would be checking the hostname under the process UTS namespace.

# This command was run keeping the below bpftrace snippets running:
$ docker run -it alpine sh
$ docker ps --no-trunc
CONTAINER ID                                                       IMAGE     COMMAND   CREATED         STATUS         PORTS     NAMES
1e04991d41d6e77c6b534d569be651d9c1680b04e64ddbcd6921d3b366d1c247   alpine    "sh"      5 minutes ago   Up 5 minutes             sweet_heyrovsky


# print UTS hostname
$ sudo bpftrace -e 'tracepoint:sched:sched_process_exec { printf("%s %s %s\n", comm, str(args->filename), curtask->nsproxy->uts_ns->name.nodename); }'
sh /bin/sh 1e04991d41d6

# print cgroup path
$ sudo bpftrace -e 'tracepoint:cgroup:cgroup_attach_task { printf("%s %s\n", comm, str(args->dst_path)); }'
systemd /system.slice/docker-1e04991d41d6e77c6b534d569be651d9c1680b04e6

Depending on implementation details like the UTS usage feels like a hack to me: it could be good for troubleshooting issues on a system, but unfit for a security solution.

Proposal

I propose to:

• Add new pulsar events for cgroup creation/deletion/attach
• Configure filtering using cgroup paths, for example:

  [process_monitor]
  target_container=/system.slice/docker-1e04991d41d6e77c6b534d569be651d9c1680b04e6
  

• Keep using map_interest[pid] as the filtering method:
  • on startup map_interest[pid] is set to track process and children for each process inside the cgroup (cheking procfs/cgroupfs)
  • the cgroup paths are added to a new hashmap map in process monitor, similar to targets/whitelist
  • on cgroup_attach_task, we check if the new cgroup is inside that map

Random info

• We could connect to the container engines and get info from them (see the tracee container-enrichment feature) This could give us extra information (eg. associate the user-facing container ID/image name with the right cgroup), but would be quite a long and complex work.
• The u64 bpf_get_current_cgroup_id(void) helper allows to get the cgroup of the current task. Still, for now I think it's better to stick to map_interest
• There is a specific cgroup array map which maybe would be more efficient than rolling our own cgroup ID array.
• Cgroup storage would allow to associate info to cgroups with automatic resource cleanup