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//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//config.v2.json for Docker or using podman inspect –type=container for Podman.
For example, we can retrieve the container image URI with:
$ podman inspect --type=container 64cabea89c87 --format "{{ .ImageName }}"
docker.io/library/alpine:latest
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 ⭐️
Top comments (0)