eBPF <error while loading map "maps/heapstore": operation not permitted>

[skpypf]

OS: Parrot (Debian Bullseye)
kernel: Linux version 6.0.0
Architecture: AMD64/X86_64

UI shows no data as if daemon isnt on. Error message below.

$sudo journalctl grep | opensnitchd
[2022-11-10 01:22:06] IMP Starting opensnitch-daemon v1.6.0rc2
[2022-11-10 01:22:06] INF Loading rules from /home/**/rules ...
[2022-11-10 01:22:06] IMP Start writing logs to /var/log/opensnitchd.log
setrlimit() failed with errno=1
[2022-11-10 01:22:06] ERR eBPF Failed to load /etc/opensnitchd/opensnitch.o: error while loading map "maps/heapstore": operation not permitted

[skpypf]

--.v1.5.2 works okay

[gustavo-iniguez-goya]

hi @skpypf ,

Could you tell me if you're running a hardened kernel, or some kind of sandbox at system level that could be restricting what processes can do? gobpf sets the memlock limit to unlimited by default, but for some reason it's failing.

Also execute the following commands to see the limits (as root), I'll post mines first:

# ulimit -l
4067276
# cat /proc/$(pgrep opensnitchd)/limits 
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             126798               126798               processes 
Max open files            1048576              1048576              files     
Max locked memory         4164890624           4164890624           bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       126798               126798               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us   

On the other hand, please, stop opensnitch, change the limits and launch the daemon manually and see if it fails:

# systemctl stop opensnitch
# ulimit -l unlimited
# /usr/bin/opensnitch -rules-path /etc/opensnitchd/rules/

As a last resort you can give CAP_SYS_RESOURCE capabilities to the daemon:
# setcap 'CAP_SYS_RESOURCE=+ep' /usr/bin/opensnitchd

[skpypf]

it looks like maybe a pam module from security-misc might be messing with the daemons ability to call on proc limits

found from root journalctl -a
Nov 10 19:04:55 parrot sudo[3016]: p : TTY=pts/0 ; PWD=/home/p ; USER=root ; COMMAND=/usr/bin/opensnitchd
Nov 10 19:04:55 parrot sudo[3016]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Nov 10 19:05:37 parrot sudo[3060]p : TTY=pts/0 ; PWD=/home/p ; USER=root ; COMMAND=/usr/bin/cat /proc/2721 3017/limits
Nov 10 19:05:37 parrot sudo[3060]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Nov 10 19:05:37 parrot sudo[3060]: pam_unix(sudo:session): session closed for user root
pam_exec(sudo:auth): /usr/libexec/security-misc/pam_faillock_not_if_x failed: exit code 1

[skpypf]

because my limits looked the same as what you posted

[skpypf]

�[2m[2022-11-11 01:05:54]�[0m �[97m�[41m ERR �[0m [REVIEW] closing due to timeout
�[2m[2022-11-11 01:06:22]�[0m �[97m�[104m IMP �[0m Start writing logs to /var/log/opensnitchd.log
�[2m[2022-11-11 01:06:22]�[0m �[97m�[43m WAR �[0m eBPF debugfs error: exit status 32
�[2m[2022-11-11 01:06:22]�[0m �[97m�[41m ERR �[0m ebpf.Start -> mount debugfs error. Report on github please: exit status 32
�[2m[2022-11-11 01:08:38]�[0m �[97m�[41m ERR �[0m [REVIEW] closing due to timeout
�[2m[2022-11-11 01:08:38]�[0m �[97m�[41m ERR �[0m [REVIEW] closing due to timeout

from log

[gustavo-iniguez-goya]

hmm, I don't think the pam module will be interfering here, but I'm just guessing.

ebpf.Start -> mount debugfs error. Report on github please: exit status 32

This error means that the dir /sys/kernel/debug/ has not been mounted, which is needed by eBPF to work. Probably that's why the v1.5.x version works, it'll be failing and falling back to proc monitor method. On v1.6.x we try to mount it.

try to mount it manually: # mount -t debugfs none /sys/kernel/debug then you should have a file named kprobe_events /sys/kernel/debug/tracing/kprobe_events

Anyway, these problems could be related to the hardening options of your installation. Let's see if we can figure out what's missing.

Please, post the output of the following commands:

# sysctl -a 
# grep -E "(KPROBE|BPF)" /boot/config-$(uname -r)

or if the file doesn't exist try: # zgrep -E "(KPROBE|BPF)" /proc/config.gz

[gustavo-iniguez-goya]

@skpypf I've installed latest ParrotOS , kernel 6.0.0-2parrot1 and the daemon 1.6.0 works just fine out of the box.

Please, post what security and hardening packages have you installed.

[skpypf]

hi sorry for late reply

i have also started a fresh install with Parrot OS also and you are correct, v.1.60.does work out of the box! Functions and looks great so far so thats awesome :)

for the sake of debugging and my own peaking interest, i have just begun the process of manually reinstalling the additional security packages i had on the previous os version, to this current working version, hoping to weed out the root cause, also using the information you provided above. so for my sake, technically the issue is resolved, but my curiosity isnt lol

[gustavo-iniguez-goya]

the thing is that we've had similar reports in the past, so if you discover what's exactly causing us to fail please post it!!