exein-io / pulsar Goto Github PK

It'd be good to support natively the Open Policy Agent project for writing Pulsar rules.

However, deploying OPA as a separate process probably comes with a very large overhead and there is no Rust support for integrating OPA as a library (only Go library right now).

Hi, I cannot find a way to use this crate as a library, is there any?

Contact Details

No response

What happened?

@MatteoNardi:

Turns out the issue is not related to the kernel version, but to Archlinux. I reproduced the issue with another Archlinux machine running 5.15, which is the same version of my development Ubuntu 22.04 machine.

Creating a file with the path /tmp/1/2/3/4/myfile emits an event with path /1/2/3/4/myfile, so I suppose it has something to do with some special behavior of the /tmp folder. For some reason, the kernel struct dentry's chain of d_parent we traverse for building the path, ends prematurely.

Relevant log output

#### Kernel/OS


[vagrant@archlinux ~]$ uname -a
Linux archlinux 5.17.1-arch1-1 #1 SMP PREEMPT Mon, 28 Mar 2022 20:55:33 +0000 x86_64 GNU/Linux

Output

test tests::unlink_file ... FAILED                           

failures:                     

---- tests::file_name stdout ----                            
[INFO  bpf_common::trace_pipe] Logging events from /sys/kernel/debug/tracing/trace_pipe                                    
69581201284 1120 deleted /file_name_1                                                                                      
69581219467 1120 created /file_name_1                                                                                      
69581228087 1120 open /tmp/file_name_1 (33345)                                                                             

69581219467 1120 created /file_name_1 (3/4)                                                                                
- pid: 1120 (OK)              
- timestamp: 69581190947 - 69581233481 (OK)                                                                                
- event type: FsEvent :: FileCreated (OK)                                                                                  
- filename: (FAIL)                                           
  |    found: StringArray { data: "/file_name_1" }                                                                         
  | expected: StringArray { data: "/tmp/file_name_1" }                                                                     

thread 'tests::file_name' panicked at 'No event found matching results', /home/matteo/projects/pulsar-experiments/bpf_common/src/test_runner.rs:155:13   
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace                                              

---- tests::unlink_file stdout ----                          
[INFO  bpf_common::trace_pipe] Logging events from /sys/kernel/debug/tracing/trace_pipe                                    
70211704597 1120 deleted /unlink_file                                                                                      

70211704597 1120 deleted /unlink_file (3/4)                                                                                
- pid: 1120 (OK)              
- timestamp: 70211693859 - 70211718252 (OK)                                                                                
- event type: FsEvent :: FileDeleted (OK)                                                                                  
- filename: (FAIL)                                           
  |    found: StringArray { data: "/unlink_file" }                                                                         
  | expected: StringArray { data: "/tmp/unlink_file" }                                                                     

thread 'tests::unlink_file' panicked at 'No event found matching results', /home/matteo/projects/pulsar-experiments/bpf_common/src/test_runner.rs:155:13 


failures:                     
    tests::file_name                                         
    tests::unlink_file                                       

Code of Conduct

• I agree to follow this project's Code of Conduct

During the last change to the event type, a regression was introduced. Specifically the rules engine checks for threats also on threats event, this means it will continue to check the same event forever.

Solution: the rule engine should check events for threat info before performing its analysis.

Implement a Pulsar module to send out Pulsar threat notifications via email through SMTP.

Currently, file-system monitor is using kprobes to attach to LSM hook points and extract file information.

This won't work on some kernel build:

If you install a probe in an inline-able function, Kprobes makes no attempt to chase down all inline instances of the function and install probes there. gcc may inline a function without being asked, so keep this in mind if you’re not seeing the probe hits you expect.

(https://docs.kernel.org/trace/kprobes.html#kprobes-features-and-limitations)

When we're running on kernels supporting BPF LSM hooks (>= 5.7), we should use those are they are more reliable.
The kernel must be compiled with CONFIG_BPF_LSM=y and cat /sys/kernel/security/lsm must list bpf.

https://docs.kernel.org/bpf/prog_lsm.html

When support for LSM BPF programs is not available, we shall fallback on the current kprobes implementation.

When sending events from eBPF programs to userspace, we always allocate the max length of bytes the given field supports. For example, in file-system-monitor, we send filenames of NAME_MAX length (1024) even when it's much shorter. Moreover, this leads us to being excessively conservative with the maximum field lengths.

We should design a data structure/protocol which allows to send only the data actually needed.

add a monitor mode to the cli to show threat [and non threat ?] events without interacting with the daemon stdout

someway related to #31

Write Pulsar logs to file. This should be added in the logging module (there's a todo placeholder in the code already).

Contact Details

No response

What happened?

Starting up Pulsar immediately results in the process-monitor module failing due to a BPF verifier error.

$ RUST_BACKTRACE=full cargo xtask pulsard
[2022-10-18T09:18:11Z ERROR pulsar::pulsard::module_manager] Module error in process-monitor: 
failed program load raw_tracepoint sched_process_exec

    Caused by:
        0: the BPF_PROG_LOAD syscall failed. Verifier output: func#0 @0
        ... TRUNCATED ...
        ; LOG_ERROR("can't get event memory");
        ... TRUNCATED ...
        1: Permission denied (os error 13)

Running on Debian on WSL2/5.15.x.

$ uname -a
Linux LAPTOP-IM56UP68 5.15.68.1-microsoft-standard-WSL2 #1 SMP Mon Sep 19 19:14:52 UTC 2022 x86_64 GNU/Linux

Running the test suite on the module hits the same issue with the following log output.

Relevant log output

$ sudo -E ./target/debug/test-suite process-monitor

running 8 tests
test process-monitor::fork_event               ... FAILED
test process-monitor::exec_event               ... FAILED
test process-monitor::exit_event               ... FAILED
test process-monitor::exit_event_no_thread     ... FAILED
test process-monitor::inherit_policy           ... FAILED
test process-monitor::exec_updates_interest    ... FAILED
test process-monitor::threads_are_ignored      ... ok
test process-monitor::exit_cleans_up_resources ... FAILED

failures:

---- process-monitor::fork_event ----
INFO:bpf_common::trace_pipe -- Logging events from /sys/kernel/debug/tracing/trace_pipe
❌ Panic: called `Result::unwrap()` on an `Err` value: running eBPF

Caused by:
    0: failed program load raw_tracepoint sched_process_exec
    1: the BPF_PROG_LOAD syscall failed. Verifier output: func#0 @0
   ... TRUNCATED ...
       from 221 to 292: safe
       104: R0=inv(id=0) R1_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R2_w=inv256 R4_w=inv(id=8) R6=inv(id=0) R7_w=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9=map_value(id=0,off=0,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
       ; event->exec.data_len = len;
       104: (63) *(u32 *)(r8 +276) = r7
        R0=inv(id=0) R1_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R2_w=inv256 R4_w=inv(id=8) R6=inv(id=0) R7_w=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9=map_value(id=0,off=0,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
       105: R0=inv(id=0) R1_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R2_w=inv256 R4_w=inv(id=8) R6=inv(id=0) R7_w=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9=map_value(id=0,off=0,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
       ; bpf_core_read_user(event->exec.argv, len & (NAME_MAX - 1), (void *)start);
       105: (07) r9 += 280
       106: R0=inv(id=0) R1_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R2_w=inv256 R4_w=inv(id=8) R6=inv(id=0) R7_w=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
       106: (bf) r1 = r9
       107: R0=inv(id=0) R1_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R2_w=inv256 R4_w=inv(id=8) R6=inv(id=0) R7_w=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
       107: (bf) r2 = r7
       108: R0=inv(id=0) R1_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R2_w=inv(id=8) R4_w=inv(id=8) R6=inv(id=0) R7_w=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
       108: (bf) r3 = r6
       109: R0=inv(id=0) R1_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R2_w=inv(id=8) R3_w=inv(id=19) R4_w=inv(id=8) R6=inv(id=19) R7_w=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
       109: (85) call bpf_probe_read_user#112
       R2 min value is negative, either use unsigned or 'var &= const'
       verification time 2186 usec
       stack depth 136
       processed 345 insns (limit 1000000) max_states_per_insn 1 total_states 25 peak_states 25 mark_read 9

    2: Permission denied (os error 13)
  | at /home/juxhin/projects/pulsar/bpf-common/src/test_runner.rs:116:64

Code of Conduct

• I agree to follow this project's Code of Conduct

Dockerize and distribute Pulsar as a public Docker image for getting started with zero overhead.

Automatic creation of Pulsar packages for main Linux distributions:

• arch
• ubuntu/debian
• fedora/redhat
• suse

Packages should be built automatically on every new tag release.

This happens only when using clang version <= 12
This is a regression caused by the argument extraction code:

https://github.com/Exein-io/pulsar/blob/99444dd952bfd1dc92af135fc92400ea6c8f92a2/modules/process-monitor/probes.bpf.c#L142-L143

The verifier complains length might be negative:

           ; event->exec.data_len = len;
           104: (63) *(u32 *)(r8 +276) = r7
            R0=inv(id=0) R1=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R2=inv256 R4=inv(id=8) R6=inv(id=0) R7=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9=map_value(id=0,off=0,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
           105: R0=inv(id=0) R1=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R2=inv256 R4=inv(id=8) R6=inv(id=0) R7=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9=map_value(id=0,off=0,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
           ; bpf_core_read_user(event->exec.argv, len & (NAME_MAX - 1), (void *)start);
           105: (07) r9 += 280
           106: R0=inv(id=0) R1=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R2=inv256 R4=inv(id=8) R6=inv(id=0) R7=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
           106: (bf) r1 = r9
           107: R0=inv(id=0) R1_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R2=inv256 R4=inv(id=8) R6=inv(id=0) R7=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
           107: (bf) r2 = r7
           108: R0=inv(id=0) R1_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R2_w=inv(id=8) R4=inv(id=8) R6=inv(id=0) R7=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
           108: (bf) r3 = r6
           109: R0=inv(id=0) R1_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R2_w=inv(id=8) R3_w=inv(id=18) R4=inv(id=8) R6=inv(id=18) R7=inv(id=8) R8=map_value(id=0,off=0,ks=4,vs=536,imm=0) R9_w=map_value(id=0,off=280,ks=4,vs=536,imm=0) R10=fp0 fp-112=mmmmmmmm fp-120=inv fp-128=ctx fp-136=mmmmmmmm
           109: (85) call bpf_probe_read_user#112
           R2 min value is negative, either use unsigned or 'var &= const'
           verification time 1779 usec
           stack depth 136
           processed 290 insns (limit 1000000) max_states_per_insn 1 total_states 23 peak_states 23 mark_read 9
           
        1: Permission denied (os error 13)

As a work-around, upgrade llvm:

apt update && apt install -y lsb-release wget software-properties-common gnupg
wget https://apt.llvm.org/llvm.sh && chmod +x llvm.sh && ./llvm.sh 15
ln -s /usr/bin/clang-15 /usr/bin/clang
ln -s /usr/bin/llvm-strip-15 /usr/bin/llvm-strip

Make it possible to send Pulsar threat alerts as notifications when running on a Linux desktop.

Support for principal desktop environments: gnome, plasma kde, etc.

The memory slowly keeps growing over time.

The cause is the hashmap inside syscall-monitor module, activity_cache, never deleting old entries

Create xtask command to create a Pulsar distribution (executable, launch scripts, rules, basic config file).

Implement a Pulsar module to send out Pulsar threat notifications to a Telegram channel.

We track binding ports and accepting connections, but we currently lack a listen event.

Contact Details

No response

What happened?

Multiple crates rely on the chrono crate which relies on a vulnerable version of the time crate (v0.1.45) containing a security advisory (CVE-2020-26235). These crates should be updated to either (a) a newer version or (b) reduced feature flags.

Relevant log output

cargo audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 487 security advisories (from /home/juxhin/.cargo/advisory-db)
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (251 crate dependencies)
Crate:     time
Version:   0.1.45
Title:     Potential segfault in the time crate
Date:      2020-11-18
ID:        RUSTSEC-2020-0071
URL:       https://rustsec.org/advisories/RUSTSEC-2020-0071
Solution:  Upgrade to >=0.2.23
Dependency tree:
time 0.1.45
└── chrono 0.4.23
    ├── procfs 0.14.2
    │   └── bpf-common 0.4.0
    │       ├── test-suite 0.4.0
    │       ├── pulsar-module-as-library 0.1.0
    │       ├── pulsar-core 0.4.0
    │       │   ├── rules-engine 0.4.0
    │       │   │   └── pulsar 0.4.0
    │       │   │       ├── pulsar-extension-module 0.1.0
    │       │   │       └── pulsar-embedded-agent 0.1.0
    │       │   ├── pulsar-extension-module 0.1.0
    │       │   ├── pulsar-embedded-agent 0.1.0
    │       │   ├── pulsar 0.4.0
    │       │   ├── process-monitor 0.4.0
    │       │   │   ├── test-suite 0.4.0
    │       │   │   └── pulsar 0.4.0
    │       │   ├── network-monitor 0.4.0
    │       │   │   ├── test-suite 0.4.0
    │       │   │   ├── pulsar-module-as-library 0.1.0
    │       │   │   └── pulsar 0.4.0
    │       │   ├── logger 0.4.0
    │       │   │   └── pulsar 0.4.0
    │       │   ├── file-system-monitor 0.4.0
    │       │   │   ├── test-suite 0.4.0
    │       │   │   └── pulsar 0.4.0
    │       │   ├── engine-api 0.4.0
    │       │   │   └── pulsar 0.4.0
    │       │   └── desktop-notifier 0.1.0
    │       │       └── pulsar 0.4.0
    │       ├── pulsar 0.4.0
    │       ├── process-monitor 0.4.0
    │       ├── network-monitor 0.4.0
    │       ├── logger 0.4.0
    │       ├── file-system-monitor 0.4.0
    │       └── desktop-notifier 0.1.0
    └── logger 0.4.0

error: 1 vulnerability found!

Code of Conduct

• I agree to follow this project's Code of Conduct

On process exit PulsarDaemon should wait for modules graceful shutdown and have a timeout as fallback in case modules won't/can't stop similar to Actix.rs workers shutdown

Compile and load proprietary modules as shared libraries.

On kernel 6.x there is the following error:

[ERROR pulsar::cli] loading BTF invalid BTF type kind `19`
    
    Caused by:
        invalid BTF type kind `19`
command exited with non-zero code `sudo -E ./target/debug/pulsar-exec pulsard`: 1

the problem seem related to aya binding generated from an old libbpf.

I have informed the aya developers and they are working on it. Should be fixed soon.

We currently don't retrieve arguments of executed programs.

During tests @krsh found that pulsar was consuming 250-650Mb of RAM.

Reducing the number of max entries for perf event maps of PERF_PAGES from 4096 to 1 from improves the situation, but we start loosing events.

Perf event maps size is configured in user space as number of pages of memory.
That number is multiplied by the number of cores, because a copy is kept on every CPU.
That number is multiplied also by the number of modules, because each module has its own map.
A bigger PERF_PAGES value increases memory usage, but makes us less susceptible to losing messages when many events are fired over a very short period of time.

The current memory usage for these maps is - n. modules * n. cores * PERF_PAGES * page size = 3 * 8 * 4096 * 4Kb = ~400Mb

These are some ideas to reduce it:

• Using a eBPF ringbuffer map instead of perf event map would reduce memory usage by the number of CPU. It's available in kernel >= 5.8. Aya doesn't support it yet.
• We could use a single pinned map for events, shared by all modules. This would reduce memory usage by the number of modules, but would reduce modularity.
• We could make PERF_PAGES setting configurable on a per-module basis. This would allow users to fine tune to their use case to their need. It would also allow us to have different defaults depending on the module type (for example, fs-monitor sends bursts of events because when a program is started, there's a file opened event for every shared library used)
• Reducing the size of events payload would allow us to reduce PERF_PAGES. A problem we have right now is that we transfer the maximum event size even for smaller events. For example, if we have a network sendmsg of 4 bytes, we send 4Kb (the max size) anyway.

Original issue author: @MatteoNardi

Add support for devices running on the LoongArch architecture.

Contact Details

No response

What happened?

We get the attached error when running docker run on a container.

Relevant log output

[2022-05-27T15:11:52Z TRACE event::process-monitor] 5081ms [24326:/usr/bin/udevadm]  Fork { ppid: 731 }
[2022-05-27T15:11:54Z TRACE event::process-monitor] 7500ms [24327:/usr/bin/bash]  Fork { ppid: 19998 }
[2022-05-27T15:11:54Z TRACE event::process-monitor] 7501ms [24327:/snap/bin/docker]  Exec { filename: "/snap/bin/docker" }
[2022-05-27T15:11:54Z TRACE event::process-monitor] 7512ms [24327:/snap/snapd/current/usr/bin/snap]  Exec { filename: "/snap/snapd/current/usr/bin/snap" }
[2022-05-27T15:11:54Z TRACE event::process-monitor] 7518ms [24339:/snap/snapd/current/usr/bin/snap]  Fork { ppid: 24327 }
[2022-05-27T15:11:54Z TRACE event::process-monitor] 7519ms [24339:/snap/snapd/15904/usr/lib/snapd/snap-seccomp]  Exec { filename: "/snap/snapd/15904/usr/lib/snapd/snap-seccomp" }
[2022-05-27T15:11:54Z WARN  trace_pipe]     snap-seccomp-24339   [002] d...1 23193.133437: exit 24339 -> 0 at 11333592100531
[2022-05-27T15:11:54Z TRACE event::process-monitor] 7520ms [24339:/snap/snapd/15904/usr/lib/snapd/snap-seccomp]  Exit { exit_code: 0 }
[2022-05-27T15:11:54Z WARN  trace_pipe]             snap-24327   [000] d...1 23193.136298: exit 24327 -> 0 at 11333594961685
[2022-05-27T15:11:54Z TRACE event::process-monitor] 7523ms [24327:/snap/snapd/current/usr/bin/snap]  Exit { exit_code: 0 }
[2022-05-27T15:11:54Z WARN  pulsar_core::pdk::process_tracker] 24327 exited 11333594961685 < 11333595737328
[2022-05-27T15:11:54Z ERROR process-monitor] Process not found in tracker 24327: process exited
[2022-05-27T15:11:54Z WARN  trace_pipe]             snap-24327   [001] d...1 23193.137098: map_interest is missing entry for pid 24327
[2022-05-27T15:11:54Z WARN  pulsar_core::pdk::process_tracker] 24327 exited 11333594961685 < 11333595877362
[2022-05-27T15:11:54Z WARN  trace_pipe]             snap-24327   [001] d...1 23193.137110: map_interest is missing entry for pid 24327
[2022-05-27T15:11:54Z ERROR fs-monitor] Process not found in tracker 24327: process exited
[2022-05-27T15:11:54Z WARN  trace_pipe]             snap-24327   [001] d...1 23193.137121: map_interest is missing entry for pid 24327
[2022-05-27T15:11:54Z TRACE event::process-monitor] 7524ms [24327:]  Exec { filename: "/snap/snapd/15904/usr/lib/snapd/snap-confine" }
[2022-05-27T15:11:54Z WARN  trace_pipe]             snap-24327   [001] d...1 23193.137122: map_interest is missing entry for pid 24327
[2022-05-27T15:11:54Z TRACE event::fs-monitor] 7524ms [24327:]  FileOpened { filename: "/usr/lib/x86_64-linux-gnu/libdl.so.2", flags: 32768 }
[2022-05-27T15:11:54Z WARN  trace_pipe]             snap-24327   [001] d...1 23193.137123: bpf_trace
[2022-05-27T15:11:54Z WARN  pulsar_core::pdk::process_tracker] 24327 exited 11333594961685 < 11333595815983
[2022-05-27T15:11:54Z WARN  trace_pipe] _printk: map_interest is missing entry for pid 24327
[2022-05-27T15:11:54Z TRACE event::fs-monitor] 7524ms [24327:]  FileOpened { filename: "/etc/ld.so.cache", flags: 32768 }
[2022-05-27T15:11:54Z ERROR fs-monitor] Process not found in tracker 24327: process exited

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

Write Pulsar logs to syslog. This should be added in the logging module (there's a todo placeholder in the code already).

Running cargo test from the root folder or from validatron/derive fails with:

/home/matteo/projects/pulsar/target/debug/deps/validatron_derive-572b783d107d6cc9: error while loading shared libraries: libtest-efede371ca078f25.so: cannot open shared object file: No such file or directory
error: test failed, to rerun pass '--lib'

validatron_derive uses proc macros. Maybe this adds the extra dependency causing the issue.
The missing libtest shared library could be found inside ~/.rustup/toolchains/.

I tried copying validatron_derive to a clean workspace and I couldn't reproduce the issue. It turns out the problem comes from our .cargo/config file:

[target.x86_64-unknown-linux-gnu]
runner = 'sudo -E'

Running all our artifacts with sudo during development was convenient since eBPF needs roots permissions to be loaded, but maybe it's time to find a better solution.

We could remove the runner config and explicitly call sudo. For binaries like pulsar-exec this is not an issue since the path is fixed (eg. cargo build && sudo ./target/debug/pulsar-exec). The problem arises for tests, where the path is automatically generated, making it hard to run it with two commands. Unfortunately, replacing unit tests with integration tests won't change the fact we have a random name, like target/debug/deps/integration_test-74139a0d8fe9d447. One possible workaround would be making the test suite a separate binary. Another solution would be to make a test_suite binary which calls the individual modules tests, enabling a specific feature flag.

Let me know what you think, maybe we can come up with better solution.

The pulsar agent pulsard is supposed to be run as a daemon. Users should interact with it by using the pulsar cli. Currently there is not way to read the agent's logs from the cli.

A nice to have feature would be to intercept all logs (maybe using the tracing crate ecosystem) and expose them to the pulsar utility.

Installer should download and place rules in the correct directory after #95 is merged

We need to implement a github action to manage the release in case of a tag push

Contact Details

No response

What happened?

The "Docs", "Concepts", "Tutorials" and "Roadmap" links in the README are broken.

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Contact Details

No response

What happened?

process-monitor fails to extract exec arguments and throws the following error:

[WARN  process_monitor::pulsar] argc (4) doens't match argv (["ps", "-e", "-o", "pid,ppid,state,command", ""]) for 20734
[WARN  process_monitor::pulsar] argc (2) doens't match argv (["ls", "--color=auto", ""]) for 20990

Tested on Ubuntu 22.04.1 LTS 5.15.0-1019-aws

Relevant log output

[WARN  process_monitor::pulsar] argc (4) doens't match argv (["ps", "-e", "-o", "pid,ppid,state,command", ""]) for 20734
[WARN  process_monitor::pulsar] argc (2) doens't match argv (["ls", "--color=auto", ""]) for 20990

Code of Conduct

• I agree to follow this project's Code of Conduct

During the weekend libtest_mimic has been updated to 0.6, updating clap to v4.

Simply updating the dependency in not enough, there are some breaking changes and more work is needed.

Currently, only the Send and Receive events contain a protocol field which differentiates between UDP and TCP. We should extend it to the other ones, if possible.
https://github.com/Exein-io/pulsar/blob/main/modules/network-monitor/src/lib.rs#L92-L127

Release open source our default Pulsar rules.

the readme and the documentation need some improvements

some of the information on the readme should be moved to the documentation to avoid maintaining stuff on two places

in particular the quick start should be a real quick start without sources compilation, we need a docker image and/or an auto install script you can fetch with curl

Create systemd service to start Pulsar as a background service at system startup.

Add support for devices running on Arm 32-bit architecture.

Event header should contain also UID (and maybe GID) and corresponding names.

IDs can be user in rules while full names are for humans that inspect the events

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 (aquasecurity/tracee#255).

Original issue author: @hdtrinh

We currently lack an event when creating or deleting links. We should support both symbolic and hard links.

While developing #119, I got sporadic segmentation faults while running the test-suite.

I tracked down the issue to unsound usage of aya apis, which allow to drop bpf::Bpf context before the map buffers using it.

I'm working on a fix.

We should update clap to latest version.

Add probe to do_mkdirat, do_renameat, do_rmdir.

#122 introduced the possibility to monitor pulsar events from the cli client pulsar-exec pulsar. The issue is that unless the pulsar-exec binary is added to the process filtering whitelist, running pulsar monitor --all will trigger a loop of events, making the whole output very hard to understand:

• Traffic between pulsard and pulsar happens over a unix socket, using a websocket
• This will make network-monitor generate Receive events for pulsar
• These events will be sent over the websocket
• This will generate more traffic, which in turn will generate more events, creating a loop

For a similar reason, we ignore all events coming from the same PID as the running pulsard executable:
https://github.com/Exein-io/pulsar/blob/cf8469e47e0fa6714853291fbb38574517ac7d33/modules/process-monitor/src/filtering/initializer.rs#L166-L172

While the cleanest solution would be to add pulsar-exec to the configuration process-monitor.whitelist_children, this would be easy to forget. We'd like to improve the default behavior, so we've decided to:

• Automatically add the current process executable path to the whitelist_children (this works because pulsard and pulsar share the same executable, pulsar-exec)
• Add an option to optionally disable this behavior

On rhel8, the test in modules/process-monitor/src/lib.rs fails because echo resolves to /bin/echo and not /usr/bin/echo as expected in https://github.com/Exein-io/pulsar/blob/main/modules/process-monitor/src/lib.rs#L183. Could we look up the path to echo first and use the resolved path in the expect check, or maybe check against both /usr/bin/echo and /bin/echo?

With the following diff, cargo test works fine on rhel8 (but may fell in other environments):

$ git diff
diff --git a/modules/process-monitor/src/lib.rs b/modules/process-monitor/src/lib.rs
index 713fc71..540b194 100644
--- a/modules/process-monitor/src/lib.rs
+++ b/modules/process-monitor/src/lib.rs
@@ -180,7 +180,7 @@ mod tests {
                 child_pid,
                 event_check!(
                     ProcessEvent::Exec,
-                    (filename, "/usr/bin/echo".into(), "exec filename")
+                    (filename, "/bin/echo".into(), "exec filename")
                 ),
             );
     }

some changes are required to support complex rules as was pointed by krsh.

• internet protocols (TCP, UDP) for networking events
• add command line in Event header
• CONTAINS operator for collections #181
• add name file (now there is only full path)
• better payload.flags #81
• add app arguments  in Exec payload #65
• replace ! with NOT in rules syntax #75
• link and unlink syscalls #64
• ip and port from SocketAddr #75
• fix fileCreated event #11
• add probe to socket listen #66
• add probe to do_mkdirat, do_renameat, do_rmdir #67

Currently, ProcessTracker won't update a process PPID (parent process id) when that parent dies.

The new parent could be PID 1 or a parent PR_SET_CHILD_SUBREAPER process.

We should find a way to correctly track it.

Currently the module status is defined in pulsar-core/src/pdk/daemon.rs like this:

pub enum ModuleStatus {
    Created,           
    Running,           
    Failed(String),    
    Stopped,           
}                      

We have no way to show a warning for running modules. Failed contains an error message, but the module is not running in that state.

For example, a module which sends events to a remote server has no way to report that the server is down. If we move to the Failed state, it will prevent us from further connection attempts.

We should add an optional warning message to the Running state, this would be picked up and shown by the CLI whe running pulsar status.