3 min read Tech

Pulsar 0.7.0. Advanced Security with Container Monitoring

Pulsar 0.7.0. Advanced Security with Container Monitoring

Pulsar 0.7.0

The Exein team has released a new version of Pulsar, 0.7.0. Pulsar is a runtime security agent for Linux systems, designed with specific focus on performance and low overhead. Powered by eBPF, it traces system activity from the Linux kernel and lets you apply security policies in real time on top of the events traced.

What's in 0.7.0 

The latest release of Pulsar marks a significant advancement in its security capabilities, introducing crucial features such as container monitoring support and SMTP integration for threats logging.

For a comprehensive overview of all the new features implemented, please refer to the detailed release notes for 0.7.0 and the documentation.

Container monitoring support

Pulsar 0.7.0 now supports container monitoring. This latest feature empowers Pulsar to extend its monitoring capabilities to containerized environments, allowing users to monitor the health and status of individual containers and identify potential vulnerabilities and threats.

How does container detection work

Pulsar employs eBPF to detect system activity. Containers are merely processes isolated by namespaces and cgroups. So, how can we determine if a new process belongs to a new container?

We can identify new processes at the following tracepoints:

  • sched_process_exec
  • sched_process_fork

Both of these receive the information about a new process in the form of task_struct. When we go deeper in the members of that struct, we can retrieve the numeric IDs of namespaces.

The mount namespace is always created, whether Docker or Podman is used. Therefore, we can detect if a new process comes with a new mount namespace.

Catching the process with a new mount namespace doesn't provide all the needed information, such as the container engine (e.g., Docker, Podman), unique container ID, and container image details. Task_struct and tracepoints don't offer these answers, but there's an alternative method.

To identify the created container, one approach is to send a user-space event for the new process, a functionality consistently performed by Pulsar. Container engines typically assign container IDs to cgroups. By examining /proc/<pid>/cgroup for any process within a container, the container ID can be extracted.

$ cat /proc/18337/cgroup

15:misc:/libpod_parent/libpod-64cabea89c8766c5432d42ee9fe93c7f853bdc

[...]

2:cpuset:/libpod_parent/libpod-64cabea89c8766c5432d42ee9fe93c7f853bdc29055a30abdbe4e26c9001d904

1:name=openrc:/libpod_parent/libpod-64cabea89c8766c5432d42ee9fe93c7f853bdc29055a30abdbe4e26c9001d904

0::/libpod_parent/libpod-64cabea89c8766c5432d42ee9fe93c7f853bdc29055a30abdbe4e26c9001d904

$ podman ps

CONTAINER ID  IMAGE                           COMMAND CREATED        STATUS        PORTS  NAMES

64cabea89c87  docker.io/library/alpine:latest /bin/sh 55 seconds ago Up 55 seconds        tender_pascal

Once obtained, detailed information about the container and its image can be retrieved by referencing /var/lib/docker/containers/<id>/config.v2.json for Docker or using podman inspect –type=container <id> for Podman.

For example, we can retrieve the container image URI with:

$ podman inspect --type=container 64cabea89c87 --format "{{ .ImageName }}"

docker.io/library/alpine:latest

Each event is annotated with a container image name and digest.

SMTP Integration for threats logging

Pulsar now features a robust SMTP integration, further improving its threat-logging capabilities. With this new feature, Pulsar can seamlessly send threat alerts via email, ensuring timely and effective communication during security incidents.

Security administrators and IT teams can now configure Pulsar to send detailed threat notifications directly to designated email addresses. This functionality ensures that crucial threat information is promptly delivered to the right personnel, enabling swift responses to potential security breaches.

To set up the SMTP feature, simply configure the following fields in the Pulsar configuration file:

[smtp-notifier]
enabled=true
receivers=<receivers email address>
server=<SMTP server>
username=<username>
password=<password>
sender=<sender email address>
port=587
encryption=starttls

Full changelog

  • Added support for monitoring containers within the core functionality #213
  • Introduced a description field in the Threat structure, providing a human-readable description of the threat #189
  • Added the namespaces field for events related to fork and exec operations. #207
  • Implemented SMTP integration within the module for logging threats to sent threats also via email #201
  • Added the ability to modules to display warnings as part of their functionality #203
  • Added syslog capabilities to the module #212
  • Introduced the enabled_by_default flag for every module, allowing the definition of default behavior #220
  • Refactored preemption in the BPF probes #188
  • Updated the Continuous Integration (CI) process to support OpenSSL. #202
  • Updated the GitHub workflow in the CI process #217
  • Resolved the issue introduced by changes in the kernel affecting the layout of the struct iov_iter #226
  • Corrected the doctest in the validation module #195
  • Implemented a check to verify the payload before applying the ruleset in the validatron module #211
  • Disabled the stack protector in the build process#205

Thank you for reading!

If you like it, don't forget to try out Pulsar and give us a star ⭐️

Share this post
Exein Tech

Exein Tech

Exein Tech is a space where our security experts delve deep into our product. A go-to source for all things cyber, from industry trends to in-depth analysis of our open-source security solution.
Rome, Italy