Tracee: Linux Runtime Security and Forensics using eBPF

Last update: Jan 5, 2023

Comments: 17

Tracee: Linux Runtime Security and Forensics using eBPF

Tracee is a Runtime Security and forensics tool for Linux. It is using Linux eBPF technology to trace your system and applications at runtime, and analyze collected events to detect suspicious behavioral patterns.

Tracee is delivered as a Docker image that once run, will start to monitor the OS and detect suspicious behavior based on a pre-defined set of behavioral patterns.

Tracee is composed of the following sub-projects:

Tracee-eBPF - Linux Tracing and Forensics using eBPF
Tracee-Rules - Runtime Security Detection Engine
libbpgo - Go library for eBPF programming using Linux's libbpf

Getting started

Prerequisites

Linux kernel version >= 4.18
Relevant kernel headers available under conventional location (see Linux Headers section for info)
libc, and the libraries: libelf and zlib
clang >= 9

Exceptions:

Tracee supports loading a pre-compiled eBPF file, in which case the kernel headers are required only for the one-time compilation, and not at runtime. See Setup Options for more info.
When using Tracee's Docker image, all of the aforementioned requirements are built into the image. The only requirement left is the kernel headers or the pre-built eBPF. See Setup Options for more info.

Quickstart with Docker

docker run --name tracee --rm --privileged -v /lib/modules/:/lib/modules/:ro -v /usr/src:/usr/src:ro -v /tmp/tracee:/tmp/tracee aquasec/tracee:latest

Note: You may need to change the volume mounts for the kernel headers based on your setup. See Linux Headers section for info.

This will run Tracee with no arguments, which defaults to detecting all available rules and reporting them as raw messages on standard output of the container. These can be further customized as detailed below.

Rules

To view the list of available rules, run the container with the --list flag.

We are currently working on creating a library of behavioral signature detections. Currently, the following are available:

Name	Description	Tags
Standard Input/Output Over Socket	Redirection of process's standard input/output to socket	"linux", "container"
Anti-Debugging	Process uses anti-debugging technique to block debugger	"linux", "container"
Code injection	Possible code injection into another process	"linux", "container"
Dynamic Code Loading	writing to executable allocated memory region	"linux", "container"
Fileless Execution	Executing a precess from memory, without a file in the disk	"linux", "container"
kernel module loading	Attempt to load a kernel module detection	"linux", "container"
LD_PRELOAD	Usage of LD_PRELOAD to allow hooks on process	"linux", "container"

Integrations

Tracee leverages falco-sidekick for sending it's detection events into other systems which are easier to consume. You can use any of falco-sidekick's supported "outputs", which includes: Slack, Mattermost, Teams, Datadog, Prometheus, StatsD, Email, Elasticsearch, Loki, PagerDuty, OpsGenie, and many more. The full list is available here.

To configure Tracee to integrate with another system, compose a falco-sidekick configuration file, and provide it to Tracee using the TRACEE_WEBHOOK_CONFIG environment variable. By default, Tracee will try to find this file at /tmp/tracee/integrations-config.yaml, so if you have followed the quickstart and started the container with /tmp/tracee mounted in, you can simply drop that file there.

A complete reference of falco-sidekick's configuration format is available here.

Setup options

Tracee is leveraging Linux's eBPF technology, which is kernel and version sensitive, and therefore needs to be specifically compiled for your hosts.

The easiest way to get started is to just let Tracee build the eBPF program for you automatically when it starts, as demonstrated by the Quickstart.
Alternatively, you can pre-compile the eBPF program, and provide it to Tracee. There are some benefits to this approach as you will not need clang and kernel headers at runtime anymore, as well as reduced risk of invoking an external program at runtime.

You can build the eBPF program in the following ways:

Clone the repo and make bpf.
make bpf DOCKER=1 to build in a Docker container which includes all development tooling.

Running this will produce a file called tracee.bpf.$kernelversion.$traceeversion.o under the dist directory.
Once you have the eBPF program artifact, you can provide it to Tracee in any of the following locations:

Path specified in TRACEE_BPF_FILE environment variable
/tmp/tracee

In this case, the full Docker image can be replaced by the lighter-weight aquasec/tracee:slim image. This image cannot build the eBPF program on its own, and is meant to be used when you have already compiled the eBPF program beforehand.

Running in container

Tracee uses a filesystem directory, by default /tmp/tracee as a work space and for default search location for file based user input. When running in a container, it's useful to mount this directory in, so that the artifacts are accessible after the container exits. For example, you can add this to the docker run command -v /tmp/tracee:/tmp/tracee.

If running in a container, regardless if it's the full or slim image, it's advisable to reuse the eBPF program across runs by mounting it from the host to the container. This way if the container builds the eBPF program it will be persisted on the host, and if the eBPF program already exists on the host, the container will automatically discover it. If you've already mounted the /tmp/tracee directory from the host (like suggested by the quickstart, you're good to go, since Tracee by default will use this location for the eBPF program. You can also mount the eBPF program file individually if it's stored elsewhere (e.g in a shared volume), for example: -v /path/to/tracee.bpf.1_2_3.4_5_6.o:/some/path/tracee.bpf.1_2_3.4_5_6.o -e TRACEE_BPF_FILE=/some/path.

If you are building the eBPF program in a container, you'll need to make the kernel headers available in the container. The quickstart example has broader mounts that works in a variety of cases, for demonstration purposes. If you want, you can narrow those mounts down to the specific directory that contains the headers on your setup, for example: -v /path/to/headers:/myheaders -e KERN_HEADERS=/myheaders. As mentioned before, a better practice for production is to pre-compile the eBPF program, in which case the kernel headers are not needed at runtime.

Permissions

If Tracee is not actually tracing, it doesn't need privileges. For example, just building the eBPF program, or listing the available options, can be done with a regular user.
For actually tracing, Tracee needs to run with sufficient capabilities:

CAP_SYS_RESOURCE (to manage eBPF maps limits)
CAP_BPF+CAP_TRACING which are available on recent kernels (>=5.8), or SYS_ADMIN on older kernels (to load and attach the eBPF programs).

Alternatively, running as root or with the --privileged flag of Docker, is an easy way to start.

Linux Headers

In order to compile the eBPF program, Tracee needs some of the Linux kernel headers. Depending on your Linux distribution, there may be different ways to obtain them.

On Ubuntu/Debian/Arch/Manjaro install the linux-headers package.
On CentOS/Fedora install the kernel-headers and kernel-devel packages.

Normally the files will be installed in /lib/modules/${kernel_version}/build which is where Tracee expects them. If you have the headers elsewhere, you can set the KERN_HEADERS environment variable with the correct location.

Note that it's important that the kernel headers match the exact version of kernel you are running. To check the current kernel version, run the command uname -r. To install a specific kernel headers version append the version to the package name: linux-headers-$(uname -r).

Note that more often than not the kernel headers files contains filesystem links to other files in other directories. Therefore, when passing the kernel headers to Tracee docker container, make sure all the necessary directories are mounted. This is why the quickstart example mounts /usr/src in addition to /lib/modules.

Owner

Aqua Security

Full lifecycle security for containers and cloud-native applications

https://github.com/aquasecurity/tracee

Comments

Additional tracing modes

We currently support three modes of operation. It may be useful to add three more. As we don't want to have a flag for each of these modes, we better change the UX to use "--trace-target" as suggested below by @itaysk

trace target | trace mode | status (issue) --- | --- | --- process | all | TODO process | new | implemented, migrate UX process | specific | implemented, migrate UX container | all | TODO container | new | implemented, migrate UX container | specific | TODO https://github.com/aquasecurity/tracee/issues/255
Feature/sort events by timestamp

Created a method to reorder events and passing them forward sorted by chronological order. For more information about the issue, see #1113 .

Algorithm

Events from the kernel are received one-by-one from the data channel. We can rely on the fact that for each CPU, all the events received from it should be ordered by timestamps (except for syscalls which are not ordered because of the way we create the event in 2 steps). So by adding to each event the source CPU, we can put it in its own CPU queue of events and get all the events to be almost ordered.

To avoid syscalls sorting problem, we can find the appropriate place to put the event in the queue from the end of it, and with maximum of 3 iterations we should find the matching place chronologically.

After we put all the events in queues according to the source CPU, we can extract each time the oldest first-in-queue event from all CPUs and send it forward.

To be able to promise that all events prior to oldest first-in-queue event arrived to other CPU's queues, we can use the fact that the CPUs' queues are ordered and be sure that if all queues sent events after given timestamp, all events prior to that timestamp have arrived. So, we can check for each CPU what is the most recent event it sent (for CPUs that sent new events). From those, we can check which one has the most ancient timestamp. Then, we can be sure that all events with older timestamps than that timestamp were received - and send them.

However, because of the other sorting problem cases (syscalls case and the vCPU case) we cannot send them right away, we need a time buffer. This part is a bit complicated - the vCPU case makes us wait at least 100ms to be sure that a vCPU didn't send a new event right after the previous (the other case is that it has no events to send). The syscalls case makes us wait about 3ms to be sure that there are no new events older than last event received in the CPU. Because the vCPU delayed event can be a syscall event (with older timestamp than the newest event in the CPU's queue), this make things event more complicated. The solution to the 2 sorting problem cases is to wait at least 100ms until we send the events up to the decided timestamp. This way we can be sure that there won't be any new events received with older timestamp than the chosen one.

To summarize the algorithm - we have a CPU queue for each CPU. We insert new events to the matching CPU's queue, and follow which CPU was updated with new event. Each interval, we check from the most recent events from each CPU which has the oldest timestamp. After a delay of at least 100ms, we send all events from queues up to that timestamp in an ordered way. This way, we can be sure that all sent events are sorted.

Concepts Used

Queues

I implemented a queue structure myself for this PR, because I need an access to the internal queue to be able to insert new events not at the tail of the queue (in the case of syscalls events that are received in unsorted way).

Pools

To reduce allocations and freeing amount, I introduced a Pool struct in this PR. The struct is used to make through it alloc and free of new event nodes which are used in the CPU queues. The pool save the freed nodes, and when alloc is required it return a saved free node if there is one saved, or alloc new one. To avoid pooling large amount of nodes, the max pooled amount is the number of allocated nodes. If the number exceeds it, the Pool will free half of the amount pooled in it.
failed to attach to raw tracepoint 'sys_enter': invalid argument in kernel 5.4

When developing external BTF feature I faced:

when trying to run tracee in a 5.4.0-80-generic kernel and the BTF file provided by btfhub. This issue is for me to investigate this further in a near future time. The same does not happen in a 5.8 kernel running on the host of the same docker container:
fea: added the pinned map for ns

This PR aims at adapting tracee to work with pinned maps with mount namespace ids. The implementation is done as a separate trace mode in order to not mess with other functions of tracee.

Usage example: tracee --trace pinned_map --mntns_pin=/path/to/pinned/map There is a point I would like to raise about this request beyond tracee mode extension itself. I have tested the application mainly with gadget-tracer from kinvolk because including tracee as an additional gadget is a primary purpose of my work. I have issues with legacy probes since several gadgets might work in parallel and use same probes which leads to conflict and error. My problem was solved by using perf-based probes which libbpf.go already provides. I understand that legacy probes are used for compatibility reason. We can try to create a fall-back to older probes if error is raised or use older probes by default and fall back to perf-probes is case of an error, if it is still necessary to keep using legacy probes in newer version of tracee. Of course, any other suggestions about how to improve this request are very much welcome. Thank you. @kinvolk @alban @mauriciovasquezbernal
[BUG] Clean up the manual cpuset mount in cgroupv1 environments
Prerequisites

[ ] This affects latest released version.

[x] This affects current development tree (origin/HEAD).

[x] There isn't an issue describing the bug.

Select one OR another:

[ ] I'm going to create a PR to solve this (assign to yourself).

[ ] Someone else should solve this.

Bug description

The cpuset diretory is mounted in the same directory as the tracee-ebpf binary.

The cpuset directory is never unmounted and/or cleaned up.

The syscall.Mount() call fails because of missing ./cpuset directory in some cases.

Steps to reproduce

See pictures above.

$ make -f builder/Makefile.tracee-make alpine-prepare $ make -f builder/Makefile.tracee-make alpine-shell ... tracee@54ab0cbb4872[/tracee]$ make all ... $ sudo ./dist/tracee-ebpf -o none containers: failed to mount cgroupv1 controller: failed to mount no such file or directory

Context

Relevant information about my setup:

Linux version: Ubuntu Jammy

Linux kernel version: 5.15.0-33-generic

Tracee version (or commit id of your tree): v0.8.0-rc-1-24-g07c8af7

LLVM version: 13

Golang version: 1.17

Additional Information (files, logs, etc)
ID for rules

Currently rules are identified by their name. If a user wants to select which rules to load, they need to give their full name on the command like, which is not ideal. We should add an ID field to signatures' metadata and use that in the --rules option.
refactor tracee-ebpf (Go)
today, most of tracee-ebpf is two huge packages: main and tracee. split tracee-ebpf's Go code into multiple packages. each package is self-contained and testable. think hard about the names and APIs of those packages.

Some ideas:

create new package tracing instead of the current tracee which will contain the core tracee-ebpf engine

rename the struct tracee to tracer

main package:

flags handling - stay in package main for now. but extract from main.go - #1248

ebpf compilations - remove #1239

check capabilities utility function - create package capabilities -

printer.go - create new package eventprinter. Factory function moves to main.go - #1266

tracee package:

tracee package needs to eventually go away, broken down into other packages

external package needs to eventually go away, the structs will be moved to respective packages

buckets cache - create new package bucketscache - #1249

stats - create new package stats. external.Stats will move to this package - #1250

configurations - create package config that includes filter, captureConfig ,outputConfig and related functions. (also create an interface for config and implement validators) - #1264

argprinters.go - move to eventprinter package (see above). remove dependency on tracee (can be a static function). replace parse misnomer with print (as the file name suggests). - #1265

containers - create new package containers. The code is already independent of tracee -

create package events - #1268

events_decoder.go - create new package events. rename to events_decoding.go

events_processor.go - create new package events. rename to event_processing.go. CopyFileByPath function should move to some utlis package or duplicated.

events.go - create new package events processEventsshould be minimal as possible, there is some code here that should be inprocessEvent`.

filters.go - create new package tracingfilters (consider the usage of pointers vs values in Filter) - #1269

TBD - tarcee.go and consts.go

related: #934, #789, #1131, #1098
[FEATURE] New network code with tests
Achievements:

Network Protocol Events with complete headers support:

IPv4, IPv6, TCP, UDP, ICMPv4, ICMPv6, DNS (all types)

Easily extend L3, L4 and L7 protocols as needed

Socket based network events (no interface binding)

New technique for missing eBPF helpers in cgroup BPF context

E2E tests based in golang signatures using created types

Code is ready for blocking network events (per protocol)

Need to define interface to provide/consume the maps

Still missing (some are for other PRs):

[ ] A PR for the network event types (temporary in this PR)

[x] non CO-RE code support

[x] execute network event tests automatically on each PR

[ ] DNS events tests

[ ] events documentation (markdown files)

[ ] tracee documentation (regarding the new network events)

[ ] Pcap capturing portion of network protocol events

Near future (as needed):

Reorganize existing network events using the sockets + cgroup approach (instead of relying on network tuples).

Derived DNS events (queries/replies) filtered from DNS protocol events

needs a definition on how these would be consumed

Protocol based events (signal anytime a protocol event happens):

bind

connect

accept

listen

setsockopt

{send,recv}msg

... all from the "proto_ops"

Socket based events (signal anytime a socket fd is accessed):

{read,write}iter

mmap

sendpage

splice_{read,write}

... all from the "socket inode" "file_ops"

Initial Checklist

[x] There is an issue describing the need for this PR.

[x] Git log contains summary of the change.

[x] Git log contains motivation and context of the change.

[x] If part of an EPIC, PR git log contains EPIC number.

[ ] If part of an EPIC, PR was added to EPIC description.

Description (git log)

aa9ec059 - e2e-rules: start golang signatures for e2e tests

8804b70b - types: add network protocol types

3b5b5a58 - network: add protocol events and types

9635ed26 - tracee.bpf.c: beginning of new cgroup based network code

c4e471da - vmlinux.h: adjust needed types and missing definitions

75afcb0f - probes: cgroupProbe type implementing the Probe interface

314a8c83 - TEMPORARY: tracee types replacement

Type of change

[ ] Bug fix (non-breaking change fixing an issue, preferable).

[ ] Quick fix (minor non-breaking change requiring no issue, use with care)

[ ] Code refactor (code improvement and/or code removal)

[x] New feature (non-breaking change, adding functionality).

[ ] Breaking change (cause existing functionality not to work as expected).

How Has This Been Tested?

Tests being included in this PR:

$ git log -1 -p | diffstat -l Makefile tests/e2e-rules/e2e-icmp.go tests/e2e-rules/e2e-icmpv6.go tests/e2e-rules/e2e-ipv4.go tests/e2e-rules/e2e-ipv6.go tests/e2e-rules/e2e-tcp.go tests/e2e-rules/e2e-udp.go tests/e2e-rules/export.go tests/e2e-rules/helpers.go tests/e2e-rules/scripts/icmp.sh tests/e2e-rules/scripts/icmpv6.sh tests/e2e-rules/scripts/ipv4.sh tests/e2e-rules/scripts/ipv6.sh tests/e2e-rules/scripts/setup.sh tests/e2e-rules/scripts/tcp.sh tests/e2e-rules/scripts/udp.sh

Reproduce the test by running:

Compile

$ make clean $ make all $ make e2e-net-rules

Run tracee

sudo ./dist/tracee-ebpf \ --output format:json \ --output option:parse-arguments \ --output option:detect-syscall \ --trace event=$(./dist/tracee-rules \ --rules-dir ./dist/e2e-net-rules \ --list-events) --trace comm=ping,nc | \ ./dist/tracee-rules \ --input-tracee file:stdin \ --input-tracee format:json \ --rules-dir ./dist/e2e-net-rules

Run a test

sudo ./tests/e2e-net-test.sh

Final Checklist:

Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.

[x] I have made corresponding changes to the documentation.

[x] My code follows the style guidelines (C and Go) of this project.

[x] I have performed a self-review of my own code.

[x] I have commented all functions/methods created, explaining what they do.

[x] I have commented my code, particularly in hard-to-understand areas.

[x] My changes generate no new warnings.

[x] I have added tests that prove my fix, or feature, is effective.

[x] New and existing unit tests pass locally with my changes.

[x] Any dependent changes have been merged and published before.

Git Log Checklist:

My commits logs have:

[x] Subject starts with "subsystem|file: description".

[x] Do not end the subject line with a period.

[x] Limit the subject line to 50 characters.

[x] Separate subject from body with a blank line.

[x] Use the imperative mood in the subject line.

[x] Wrap the body at 72 characters.

[x] Use the body to explain what and why instead of how.

Extra Info

Performance does not look bad when tracing IPv4, TCP, UDP and DNS altogether:
capabilities: mount cpuset in tmpfs when in a container
This fixes the logic of creating the cgroup mount when in a container using cgroupv1. It adds an error check and creates the mount in tmpfs instead of the src directory.

Initial Checklist

[x] There is an issue describing the need for this PR.

[x] Git log contains summary of the change.

[x] Git log contains motivation and context of the change.

Description (git log)

commit 04af9297f788782231e58cc831148f4f275a30e1 (HEAD -> breakup-capabilities-check-and-drop, pfork/breakup-capabilities-check-and-drop) Author: grantseltzer [email protected] Date: Wed Jul 13 18:17:08 2022 -0400

containers: move cpuset cgroup mount to tmpfs Signed-off-by: grantseltzer <[email protected]>

commit d10100f36c7c0a64f762d7f5619d87436d5ecb45 Author: grantseltzer [email protected] Date: Wed Jul 13 10:33:55 2022 -0400

Add error check to cpuset mkdir call Signed-off-by: grantseltzer <[email protected]>

Fixes #1945

Type of change

[x] Bug fix (non-breaking change fixing an issue, preferable).

How Has This Been Tested?

#1945 contains reproduction instructions
[BUG] intermittent errors after PR 1202 (drop privileges)
Prerequisites

[ ] This affects latest released version.

[x] This affects current development tree (origin/HEAD).

[x] There isn't an issue describing the bug.

Select one OR another:

[ ] I'm going to create a PR to solve this (assign to yourself).

[x] Someone else should solve this.

Bug description

I'm executing tests in multiple environments through the DAILY TESTS and I have observed that we're currently getting intermittent failures after merging commits 6b0cad48 and bf0600a0. I know tests are intermittently failing because after an initial run I got the following tests failing:

CO-RE (TRC-3, focalhwe-5.13) CO-RE (TRC-4, focalhwe-5.13) CO-RE (TRC-9, focalhwe-5.13) CO-RE (TRC-14, focalhwe-5.13)

CO-RE (TRC-4, jammy-5.15) CO-RE (TRC-11, jammy-5.15)

Beside the known failure of GKE kernel for TRC-9.

After running tests again, most of them passed but:

CO-RE (TRC-4, focalhwe-5.13)

ALL the errors were similar to the one bellow:

Meaning that it might be that tracee dropped privilege BEFORE the eBPF program load+attachment.

Steps to reproduce

Steps to reproduce the issue:

Run the CO-RE daily tests and observe intermittent issues.

Additional info

The full log for the last error can be found at:

https://github.com/aquasecurity/tracee/runs/6765902831?check_suite_focus=true

tracee-ebpf: mount event missing source field

Hi, I'm using tracee-ebpf to collect mount events. However, the "source" field misses sometimes.

Here is an example (you can start a docker container a few times and see this scenario):

Also, you can notice that the "filesystem type" is also missing sometimes. The example shows that LTTng gives mount type "bind", while tracee gives nothing.

{
  "processName":"runc:2:INIT]",
  "containerId":"2af0bc626525",
  "eventId":"165",
  "eventName":"mount",
  "argsNum":3,
  "returnValue":0,
  "args":[{ 
    "name":"target",
    "type":"const char*",
"value":"/var/lib/docker/overlay2/6fd16b36923947538d76e6b781d08f08d64ac69f513e7b24a889fa4337a948e0/merged/etc/resolv.conf"
  },{
    "name":"mountflags",
    "type":"unsigned long",
    "value":278528
  },{
    "name":"data",
    "type":"const void*",
    "value":0}
]}

As a comparison, LTTng will output this event as:

{
  "pid_ns":4026532645,
  "vtid":1,
  "event":"mount",
  "comm":"runc:[2:INIT]",
  "args":[{
    "Name":"dev_name",
    "Value":"/sys/fs/cgroup/devices/docker/2af0bc6265257c960d559b38134bf212b3292f226c586dd9295b42faa2945df7"
  },{
    "Name":"dir_name",
"Value":"/var/lib/docker/overlay2/6fd16b36923947538d76e6b781d08f08d64ac69f513e7b24a889fa4337a948e0/merged/etc/resolv.conf"
  },{
    "Name":"type","Value":"bind"
  },{
    "Name":"flags","Value":"278528"
  }],
  "tid":220199
}

tracee: add event derivation registering
Initial Checklist

[ ] There is an issue describing the need for this PR.

[x] Git log contains summary of the change.

[x] Git log contains motivation and context of the change.

[ ] If part of an EPIC, PR git log contains EPIC number.

[ ] If part of an EPIC, PR was added to EPIC description.

Description (git log)

Copy and paste the git log here.

Fixes: #issue_number

Type of change

[ ] Bug fix (non-breaking change fixing an issue, preferable).

[ ] Quick fix (minor non-breaking change requiring no issue, use with care)

[x] Code refactor (code improvement and/or code removal)

[x] New feature (non-breaking change adding functionality).

[ ] Breaking change (cause existing functionality not to work as expected).

How Has This Been Tested?

Tests being included in this PR:

[ ] Test File A

[ ] Test File B

Reproduce the test by running:

command 01

command 02

Final Checklist:

Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.

[x] I have made corresponding changes to the documentation.

[x] My code follows the style guidelines (C and Go) of this project.

[x] I have performed a self-review of my own code.

[x] I have commented all functions/methods created explaining what they do.

[x] I have commented my code, particularly in hard-to-understand areas.

[x] My changes generate no new warnings.

[ ] I have added tests that prove my fix, or feature, is effective.

[x] New and existing unit tests pass locally with my changes.

[x] Any dependent changes have been merged and published before.

Git Log Checklist:

My commits logs have:

[x] Subject starts with "subsystem|file: description".

[x] Do not end the subject line with a period.

[x] Limit the subject line to 50 characters.

[x] Separate subject from body with a blank line.

[x] Use the imperative mood in the subject line.

[x] Wrap the body at 72 characters.

[x] Use the body to explain what and why instead of how.
tracee: refactor signals done channel
To process signals we use a done channel which is passed down as argument. But it would be best to use a Context, so to fix it we are using signal.NotifyContext which returns a context that will be closed in case the expected signals are sent.

Initial Checklist

[ ] There is an issue describing the need for this PR.

[ ] Git log contains summary of the change.

[ ] Git log contains motivation and context of the change.

[ ] If part of an EPIC, PR git log contains EPIC number.

[ ] If part of an EPIC, PR was added to EPIC description.

Description (git log)

Copy and paste the git log here.

Fixes: #issue_number

Type of change

[ ] Bug fix (non-breaking change fixing an issue, preferable).

[ ] Quick fix (minor non-breaking change requiring no issue, use with care)

[ ] Code refactor (code improvement and/or code removal)

[ ] New feature (non-breaking change adding functionality).

[ ] Breaking change (cause existing functionality not to work as expected).

How Has This Been Tested?

Tests being included in this PR:

[ ] Test File A

[ ] Test File B

Reproduce the test by running:

command 01

command 02

Final Checklist:

Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.

[ ] I have made corresponding changes to the documentation.

[ ] My code follows the style guidelines (C and Go) of this project.

[ ] I have performed a self-review of my own code.

[ ] I have commented all functions/methods created explaining what they do.

[ ] I have commented my code, particularly in hard-to-understand areas.

[ ] My changes generate no new warnings.

[ ] I have added tests that prove my fix, or feature, is effective.

[ ] New and existing unit tests pass locally with my changes.

[ ] Any dependent changes have been merged and published before.

Git Log Checklist:

My commits logs have:

[ ] Subject starts with "subsystem|file: description".

[ ] Do not end the subject line with a period.

[ ] Limit the subject line to 50 characters.

[ ] Separate subject from body with a blank line.

[ ] Use the imperative mood in the subject line.

[ ] Wrap the body at 72 characters.

[ ] Use the body to explain what and why instead of how.
network: add cgroup based pcap capture code
Description (git log)

network: add cgroup based pcap capture code

The new cgroup based pcap capture code is able to capture ANY TCP, UDP or ICMP packet for both IPv4 and IPv6 protocols from any physical (L1) and link (L2) layers.

Differently than the current existing pcap capture code, this new approach allows tracee to capture packets from any process on the host or in a container, independently of the interfaces they are using to communicate. There is no need to bind a tc hook program to a specific interface now.

$ tracee-ebpf --capture network

There is also a mid layer code responsible for managing opened pcap files using a LRU cache (so tracee has a limit on amount of opened files being used).

Another feature is the capability of selecting one or multiple pcap file types to have captured:

per process (processes/{host,container_id}/process_TID_TS.pcap)

per container (containers/container_id.pcap)

per command (commands/{host,container_id}/command.pcap)

$ tracee-ebpf --capture network --capture netpcap:process,container,command

NOTE: This allows the previous tc hook based network code to be retired and, with it, the need for specifying an interface to be hooked to.

Fixes: #2126 Fixes: #2096 Related: #2152

Type of change

[ ] Bug fix (non-breaking change fixing an issue, preferable).

[ ] Quick fix (minor non-breaking change requiring no issue, use with care)

[ ] Code refactor (code improvement and/or code removal)

[x] New feature (non-breaking change adding functionality).

[ ] Breaking change (cause existing functionality not to work as expected).

How Has This Been Tested?

Execute the commands described in the git log message and check for the created pcap files under /tmp/tracee/out/pcap/ directory.

Final Checklist:

Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.

[x] I have made corresponding changes to the documentation.

[x] My code follows the style guidelines (C and Go) of this project.

[x] I have performed a self-review of my own code.

[x] I have commented all functions/methods created explaining what they do.

[x] I have commented my code, particularly in hard-to-understand areas.

[x] My changes generate no new warnings.

[ ] I have added tests that prove my fix, or feature, is effective.

[x] New and existing unit tests pass locally with my changes.

[x] Any dependent changes have been merged and published before.

Git Log Checklist:

My commits logs have:

[x] Subject starts with "subsystem|file: description".

[x] Do not end the subject line with a period.

[x] Limit the subject line to 50 characters.

[x] Separate subject from body with a blank line.

[x] Use the imperative mood in the subject line.

[x] Wrap the body at 72 characters.

[x] Use the body to explain what and why instead of how.
kernel events that are based on filters broken by recent commit

Description

The following commit has broken the future print_mem_dump events, which are based on filters provided by the user to be arguments to the event: https://github.com/aquasecurity/tracee/commit/5d5fb072acb749a0397ede6c3c3afa37d8a2460e

This issue is cause by the fact that the filtered arguments are populated in userspace. This issue doesn't affect symbols_loaded event because it's origin is the userspace. This causes the events to not be printed to the user.

Additional details
ebpf: split code
Initial Checklist

[ ] There is an issue describing the need for this PR.

[ ] Git log contains summary of the change.

[ ] Git log contains motivation and context of the change.

[ ] If part of an EPIC, PR git log contains EPIC number.

[ ] If part of an EPIC, PR was added to EPIC description.

Description (git log)

Copy and paste the git log here.

Fixes: #issue_number

Type of change

[ ] Bug fix (non-breaking change fixing an issue, preferable).

[ ] Quick fix (minor non-breaking change requiring no issue, use with care)

[x] Code refactor (code improvement and/or code removal)

[ ] New feature (non-breaking change adding functionality).

[ ] Breaking change (cause existing functionality not to work as expected).

How Has This Been Tested?

Tests being included in this PR:

[ ] Test File A

[ ] Test File B

Reproduce the test by running:

command 01

command 02

Final Checklist:

Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.

[x] I have made corresponding changes to the documentation.

[x] My code follows the style guidelines (C and Go) of this project.

[x] I have performed a self-review of my own code.

[ ] I have commented all functions/methods created explaining what they do.

[ ] I have commented my code, particularly in hard-to-understand areas.

[x] My changes generate no new warnings.

[ ] I have added tests that prove my fix, or feature, is effective.

[x] New and existing unit tests pass locally with my changes.

[x] Any dependent changes have been merged and published before.

Git Log Checklist:

My commits logs have:

[x] Subject starts with "subsystem|file: description".

[x] Do not end the subject line with a period.

[x] Limit the subject line to 50 characters.

[x] Separate subject from body with a blank line.

[x] Use the imperative mood in the subject line.

[x] Wrap the body at 72 characters.

[x] Use the body to explain what and why instead of how.
ebpf: use new kernel symbols from libbpfgo
use new libbpgo kernel symbols Refresh method so that kernel symbols will be up-to-date throughout all components

Initial Checklist

[x] There is an issue describing the need for this PR.

[x] Git log contains summary of the change.

[x] Git log contains motivation and context of the change.

[ ] If part of an EPIC, PR git log contains EPIC number.

[ ] If part of an EPIC, PR was added to EPIC description.

Description (git log)

Author: RoiKol <[email protected]> Date: Tue Jan 3 19:47:02 2023 +0200 ebpf: use new kernel symbols from libbpfgo use new libbpgo kernel symbols Refresh method so that kernel symbols will be up-to-date throughout all components

Fixes: #2526

Type of change

[x] Bug fix (non-breaking change fixing an issue, preferable).

[ ] Quick fix (minor non-breaking change requiring no issue, use with care)

[ ] Code refactor (code improvement and/or code removal)

[ ] New feature (non-breaking change adding functionality).

[ ] Breaking change (cause existing functionality not to work as expected).

How Has This Been Tested?

using POC of seq_ops hooks (can be provided). now we get the correct values for hooked_seq_ops event:

19:19:35:747254 0 insmod 49240 49240 0 hooked_seq_ops hooked_seq_ops: map[tcp4_seq_ops_show:{hook_tcp4_seq_show main}]

Final Checklist:

Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.

[x] I have made corresponding changes to the documentation.

[x] My code follows the style guidelines (C and Go) of this project.

[x] I have performed a self-review of my own code.

[x] I have commented all functions/methods created explaining what they do.

[x] I have commented my code, particularly in hard-to-understand areas.

[x] My changes generate no new warnings.

[x] I have added tests that prove my fix, or feature, is effective.

[x] New and existing unit tests pass locally with my changes.

[x] Any dependent changes have been merged and published before.

Git Log Checklist:

My commits logs have:

[x] Subject starts with "subsystem|file: description".

[x] Do not end the subject line with a period.

[x] Limit the subject line to 50 characters.

[x] Separate subject from body with a blank line.

[x] Use the imperative mood in the subject line.

[x] Wrap the body at 72 characters.

[x] Use the body to explain what and why instead of how.

Tracee: Linux Runtime Security and Forensics using eBPF

Tracee: Linux Runtime Security and Forensics using eBPF

Getting started

Prerequisites

Quickstart with Docker

Rules

Integrations

Setup options

Running in container

Permissions

Linux Headers

Owner

Aqua Security

Comments

Additional tracing modes

Feature/sort events by timestamp

Algorithm

Concepts Used

Queues

Pools

failed to attach to raw tracepoint 'sys_enter': invalid argument in kernel 5.4

fea: added the pinned map for ns

[BUG] Clean up the manual cpuset mount in cgroupv1 environments

Prerequisites

Bug description

Steps to reproduce

Context

Additional Information (files, logs, etc)

ID for rules

refactor tracee-ebpf (Go)

[FEATURE] New network code with tests

Initial Checklist

Description (git log)

Type of change

How Has This Been Tested?

Final Checklist:

Git Log Checklist:

Extra Info

capabilities: mount cpuset in tmpfs when in a container

Initial Checklist

Description (git log)

Type of change

How Has This Been Tested?

[BUG] intermittent errors after PR 1202 (drop privileges)

Prerequisites

Bug description

Steps to reproduce

Additional info

tracee-ebpf: mount event missing source field

tracee: add event derivation registering

Initial Checklist

Description (git log)

Type of change

How Has This Been Tested?

Final Checklist:

Git Log Checklist:

tracee: refactor signals done channel

Initial Checklist

Description (git log)

Type of change

How Has This Been Tested?

Final Checklist:

Git Log Checklist:

network: add cgroup based pcap capture code

Description (git log)

Type of change

How Has This Been Tested?

Final Checklist:

Git Log Checklist:

kernel events that are based on filters broken by recent commit

Description

Additional details

ebpf: split code

Initial Checklist

Description (git log)

Type of change

How Has This Been Tested?

Final Checklist:

Git Log Checklist:

ebpf: use new kernel symbols from libbpfgo