search

evilsocket / opensnitch

OpenSnitch is a GNU/Linux interactive application firewall inspired by Little Snitch.
GNU General Public License v3.0
9.88k stars 490 forks source link

No events captured under Manjaro/Arch. #833

Closed famewolf closed 1 year ago

famewolf commented 1 year ago

Please, check the FAQ and Known Problems pages before creating the bug report: https://github.com/evilsocket/opensnitch/wiki/FAQs https://github.com/evilsocket/opensnitch/wiki/Known-problems

Describe the bug Installed both opensnitch and opensnitch-git on Manjaro as well as the ebf modules for both and ran the program. In all cases the ui ran but no events were captured. There is no service called opensnitch under systemctl. I ensured all the python support packages were installed and ran a couple of pip workaround commands but nothing resolved the lack of events.

Include the following information:

To Reproduce Describe in detail as much as you can what happened.

Steps to reproduce the behavior: Run the program, go to the UI and open the event logs..no events listed.

Post error logs: No crashes

If the daemon doesn't start:

Screenshots If applicable, add screenshots to help explain your problem. It may help to understand the issue much better.

Additional context python-protobuf and python-grpcio installed. slugify does not exist in any form.

gustavo-iniguez-goya commented 1 year ago

Hi @famewolf ,

You only need one package: opensnitch (1.5.x) or opensnitch-git (1.6.x).

Remove one of them and it should start working.

famewolf commented 1 year ago

I tried both of them one at a time and neither worked.

On February 5, 2023 12:37:25 PM Gustavo Iñiguez Goia @.***> wrote:

Hi @famewolf , You only need one package: opensnitch (1.5.x) or opensnitch-git (1.6.x). Remove one of them and it should start working. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

gustavo-iniguez-goya commented 1 year ago

ok, I need you to follow the next steps in order to verify that your current installation is fine (ignore steps if already done):

This message setrlimit() failed with errno=1 worries me a little bit. It's failing to load the eBPF modules, usually caused by hardened kernels or hardening parameters. But in any case, the daemon should run using proc monitor method.

pnavinash commented 1 year ago

I have a similar issue after the recent update. As far as I can make out from status and logs there are no errors, just no intercepts.

OS: Manjaro 22.0.2 up to date

[wpkg@lwrapper ~]$ pgrep -a opensnitch
485 /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules
1452 /usr/bin/python /usr/bin/opensnitch-ui
[wpkg@lwrapper ~]$ systemctl status opensnitchd
● opensnitchd.service - OpenSnitch is a GNU/Linux application firewall.
     Loaded: loaded (/usr/lib/systemd/system/opensnitchd.service; enabled; preset: disabled)
     Active: active (running) since Tue 2023-02-07 19:46:13 IST; 33min ago
       Docs: https://github.com/evilsocket/opensnitch/wiki
   Main PID: 485 (opensnitchd)
      Tasks: 13 (limit: 14024)
     Memory: 44.0M
        CPU: 9.359s
     CGroup: /system.slice/opensnitchd.service
             └─485 /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules

Feb 07 19:46:13 lwrapper systemd[1]: Started OpenSnitch is a GNU/Linux application firewall..
Feb 07 19:46:13 lwrapper opensnitchd[485]: [2023-02-07 14:16:13]  IMP  Starting opensnitch-daemon v1.5.5
Feb 07 19:46:13 lwrapper opensnitchd[485]: [2023-02-07 14:16:13]  INF  Loading rules from /etc/opensnitchd/rules ...
[wpkg@lwrapper ~]$ opensnitchd -version
1.5.5
[wpkg@lwrapper ~]$ ls -l /usr/bin/opensnitchd /usr/local/bin/opensnitchd
ls: cannot access '/usr/local/bin/opensnitchd': No such file or directory
-rwxr-xr-x 1 root root 13487704 Feb  6 08:36 /usr/bin/opensnitchd
[wpkg@lwrapper ~]$ sudo sysctl -a | grep bpf
[sudo] password for wpkg: 
kernel.bpf_stats_enabled = 0
kernel.unprivileged_bpf_disabled = 2
net.core.bpf_jit_enable = 1
net.core.bpf_jit_harden = 0
net.core.bpf_jit_kallsyms = 1
net.core.bpf_jit_limit = 264241152
[wpkg@lwrapper ~]$ pacman -Q opensnitch-ebpf-module-stable 
opensnitch-ebpf-module-stable 1.5.5-1
[wpkg@lwrapper ~]$ tail -n 15 /var/log/opensnitchd.log
[2023-02-07 13:51:14]  ERR  getting notifications: rpc error: code = Unavailable desc = transport is closing <nil>
[2023-02-07 13:51:14]  WAR  Error while pinging UI service: rpc error: code = Unavailable desc = transport is closing, state: CONNECTING

[2023-02-07 13:51:19]  IMP  Got signal: terminated
[2023-02-07 13:51:19]  ERR  Connection to the UI service lost.
[2023-02-07 13:51:25]  WAR  queue stuck, closing by timeout
[2023-02-07 13:51:25]  WAR  Queue.destroy(), nfq_close() not closed: -1
[2023-02-07 13:54:29]  IMP  Start writing logs to /var/log/opensnitchd.log
[2023-02-07 14:12:51]  ERR  Error reading firewall configuration from disk /etc/opensnitchd/system-fw.json: open /etc/opensnitchd/system-fw.json: no such file or directory
[2023-02-07 14:12:51]  ERR  Error parsing configuration /etc/opensnitchd/default-config.json: unexpected end of JSON input

[2023-02-07 14:13:42]  IMP  Got signal: terminated
[2023-02-07 14:13:48]  WAR  queue stuck, closing by timeout
[2023-02-07 14:13:48]  WAR  Queue.destroy(), nfq_close() not closed: -1
[2023-02-07 14:16:13]  IMP  Start writing logs to /var/log/opensnitchd.log
gustavo-iniguez-goya commented 1 year ago

Hi @pnavinash ,

That looks like a different problem. At least in your case the daemon is running.

Please, set LogLevel to DEBUG (Preferences -> Nodes), execute curl https://github.com and post the log file /var/log/opensnitchd.log

Also, please, close the GUI, and launch it from the shell, to see if it's outputting any errors to stdout.

weltenwort commented 1 year ago

I'm seeing the same with 1.5.5 on Arch Linux. The UI doesn't seem to be able to establish a connection to the daemon since the local node is not listed. So the node preferences in the UI don't take effect.

The UI prints the following on stdout/stderr:

Themes not available. Install qt-material if you want to change GUI's appearance: pip3 install qt-material.
Loading translations: /usr/lib/python3.10/site-packages/opensnitch/i18n locale: en_US
exception loading ipasn db: No module named 'pyasn'
Install python3-pyasn to display IP's network name.

Neither of these sound like they should keep it from communicating with the daemon, should they?

pnavinash commented 1 year ago

@gustavo-iniguez-goya : Thank you, do you want me to continue to post here or create a new issue?

As @weltenwort posted above, changing the log level in UI does not seem to make it through.

Here is what I did:

  1. Launched UI from terminal 
    
opensnitch-ui                                                                                                                                                                                     4.3m
Themes not available. Install qt-material if you want to change GUI's appearance: pip3 install qt-material.
Loading translations: /usr/lib/python3.10/site-packages/opensnitch/i18n locale: en_US
exception loading ipasn db: No module named 'pyasn'
Install python3-pyasn to display IP's network name.
2. "Updated" log level to Debug and applied.
3. Did a `curl https://github.com` and here are the logs from `/var/log/opensnitch.log` for the last 2 days. It was working 2 days ago as far as I remember.

[wpkg@lwrapper ~]$ tail -n 50 /var/log/opensnitchd.log [2023-02-05 20:25:49] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-05 20:25:52] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-05 20:25:54] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-05 20:25:56] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-05 20:25:58] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-05 20:25:58] ERR getting notifications: rpc error: code = Unavailable desc = transport is closing

[2023-02-05 20:25:58] IMP Got signal: terminated [2023-02-05 20:25:59] ERR Connection to the UI service lost. [2023-02-05 20:26:04] WAR queue stuck, closing by timeout [2023-02-05 20:26:04] WAR Queue.destroy(), nfq_close() not closed: -1 [2023-02-06 14:13:31] IMP Start writing logs to /var/log/opensnitchd.log [2023-02-06 15:25:51] IMP Added new rule: deny if process.path is '/usr/lib/electron19/electron' [2023-02-06 17:02:06] IMP Added new rule: deny if process.path is '/usr/bin/kded5' [2023-02-06 17:43:19] IMP Added new rule: allow if process.path is '/usr/bin/mpv' [2023-02-06 18:24:02] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-06 18:24:04] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-06 18:24:06] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-06 18:24:08] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-06 18:24:10] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-06 18:24:10] ERR getting notifications: rpc error: code = Unavailable desc = transport is closing

[2023-02-06 18:24:10] IMP Got signal: terminated [2023-02-06 18:24:16] WAR queue stuck, closing by timeout [2023-02-06 18:24:16] WAR Queue.destroy(), nfq_close() not closed: -1 [2023-02-07 13:24:03] IMP Start writing logs to /var/log/opensnitchd.log [2023-02-07 13:25:08] WAR ebpf warning: eBPF packet with unknown source IP: 192.112.36.4 [2023-02-07 13:25:10] WAR ebpf warning: eBPF packet with unknown source IP: 192.112.36.4 [2023-02-07 13:25:11] WAR ebpf warning: eBPF packet with unknown source IP: 192.33.4.12 [2023-02-07 13:25:13] WAR ebpf warning: eBPF packet with unknown source IP: 192.33.4.12 [2023-02-07 13:48:19] IMP Start writing logs to /var/log/opensnitchd.log [2023-02-07 13:51:06] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = Deadline Exceeded, state: READY [2023-02-07 13:51:08] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-07 13:51:10] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-07 13:51:12] WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY [2023-02-07 13:51:14] ERR getting notifications: rpc error: code = Unavailable desc = transport is closing [2023-02-07 13:51:14] WAR Error while pinging UI service: rpc error: code = Unavailable desc = transport is closing, state: CONNECTING

[2023-02-07 13:51:19] IMP Got signal: terminated [2023-02-07 13:51:19] ERR Connection to the UI service lost. [2023-02-07 13:51:25] WAR queue stuck, closing by timeout [2023-02-07 13:51:25] WAR Queue.destroy(), nfq_close() not closed: -1 [2023-02-07 13:54:29] IMP Start writing logs to /var/log/opensnitchd.log [2023-02-07 14:12:51] ERR Error reading firewall configuration from disk /etc/opensnitchd/system-fw.json: open /etc/opensnitchd/system-fw.json: no such file or directory [2023-02-07 14:12:51] ERR Error parsing configuration /etc/opensnitchd/default-config.json: unexpected end of JSON input

[2023-02-07 14:13:42] IMP Got signal: terminated [2023-02-07 14:13:48] WAR queue stuck, closing by timeout [2023-02-07 14:13:48] WAR Queue.destroy(), nfq_close() not closed: -1 [2023-02-07 14:16:13] IMP Start writing logs to /var/log/opensnitchd.log

gustavo-iniguez-goya commented 1 year ago

WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY

hmm, I'll investigate this error

weltenwort commented 1 year ago

WAR Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY

hmm, I'll investigate this error

Thanks for being willing to help us out. This might be a red herring, though, since these log lines might be from before the update was applied. For me 1.4.3 produced these, but worked flawlessly.

pnavinash commented 1 year ago

Here is my update log if it helps. I was using opensnitch from AUR and it seems like Arch now ships it in community repo. You'll also see my installation and removal of -git from AUR to see if that works.

[wpkg@lwrapper ~]$ rg opensnitch /var/log/pacman.log
1295:[2022-12-17T03:00:54+0530] [PACMAN] Running 'pacman --upgrade --noconfirm -- /home/wpkg/.cache/paru/clone/opensnitch/opensnitch-1.5.2-1-x86_64.pkg.tar.zst'
1297:[2022-12-17T03:00:54+0530] [ALPM] installed opensnitch (1.5.2-1)
1304:[2022-12-17T03:00:54+0530] [PACMAN] Running 'pacman --database --asexplicit -- opensnitch'
1305:[2022-12-17T03:02:40+0530] [PACMAN] Running 'pacman --upgrade --noconfirm -- /home/wpkg/.cache/paru/clone/opensnitch-ebpf-module-stable/opensnitch-ebpf-module-stable-1.5.2-7-x86_64.pkg.tar.zst'
1307:[2022-12-17T03:02:40+0530] [ALPM] installed opensnitch-ebpf-module-stable (1.5.2-7)
1310:[2022-12-17T03:02:40+0530] [PACMAN] Running 'pacman --database --asexplicit -- opensnitch-ebpf-module-stable'
2776:[2022-12-22T19:52:45+0530] [PACMAN] Running 'pacman --upgrade --noconfirm -- /home/wpkg/.cache/paru/clone/opensnitch-ebpf-module-stable/opensnitch-ebpf-module-stable-1.5.2-9-x86_64.pkg.tar.zst'
2822:[2022-12-22T19:52:49+0530] [ALPM] upgraded opensnitch-ebpf-module-stable (1.5.2-7 -> 1.5.2-9)
6754:[2023-01-24T19:40:57+0530] [PACMAN] Running 'pacman --upgrade --noconfirm -- /home/wpkg/.cache/paru/clone/opensnitch/opensnitch-1.5.3-1-x86_64.pkg.tar.zst'
6801:[2023-01-24T19:41:02+0530] [ALPM] upgraded opensnitch (1.5.2-1 -> 1.5.3-1)
6808:[2023-01-24T19:43:04+0530] [PACMAN] Running 'pacman --upgrade --noconfirm -- /home/wpkg/.cache/paru/clone/opensnitch-ebpf-module-stable/opensnitch-ebpf-module-stable-1.5.3-1-x86_64.pkg.tar.zst'
6855:[2023-01-24T19:43:11+0530] [ALPM] upgraded opensnitch-ebpf-module-stable (1.5.2-9 -> 1.5.3-1)
8829:[2023-02-06T19:49:18+0530] [PACMAN] Running 'pacman --upgrade --noconfirm -- /home/wpkg/.cache/paru/clone/opensnitch-ebpf-module-stable/opensnitch-ebpf-module-stable-1.5.5-1-x86_64.pkg.tar.zst'
8880:[2023-02-06T19:49:28+0530] [ALPM] upgraded opensnitch-ebpf-module-stable (1.5.3-1 -> 1.5.5-1)
9008:[2023-02-07T19:18:19+0530] [ALPM] upgraded opensnitch (1.5.3-1 -> 1.5.5-1)
9200:[2023-02-07T19:42:45+0530] [PACMAN] Running 'pacman --upgrade -- /home/wpkg/.cache/paru/clone/opensnitch-git/opensnitch-git-1.6.0rc4.r34.156e936-1-x86_64.pkg.tar.zst'
9202:[2023-02-07T19:42:51+0530] [ALPM] removed opensnitch (1.5.5-1)
9203:[2023-02-07T19:42:51+0530] [ALPM] installed opensnitch-git (1.6.0rc4.r34.156e936-1)
9205:[2023-02-07T19:42:51+0530] [ALPM-SCRIPTLET] Enable opensnitchd as a systemd service:
9206:[2023-02-07T19:42:51+0530] [ALPM-SCRIPTLET] systemctl enable --now opensnitchd
9214:[2023-02-07T19:42:52+0530] [PACMAN] Running 'pacman --database --asexplicit -- opensnitch-git'
9215:[2023-02-07T19:43:14+0530] [PACMAN] Running 'pacman -Syu opensnitch'
9219:[2023-02-07T19:43:20+0530] [ALPM] removed opensnitch-git (1.6.0rc4.r34.156e936-1)
9222:[2023-02-07T19:43:20+0530] [ALPM-SCRIPTLET] sudo rm /var/log/opensnitchd.log
9224:[2023-02-07T19:43:20+0530] [ALPM] installed opensnitch (1.5.5-1)
gustavo-iniguez-goya commented 1 year ago

hmmm, on the one hand I've realized that the package opensnitch-git does not stop the daemon after uninstalling. So if you install opensnitch after that, then you'll run into the error reported by @famewolf , because the package opensnitch will try to start the daemon 1.5.5 but the 1.6.x hasn't been stopped yet.

On the other hand, on a clean Arch install, the daemon 1.5.5 doesn't connect to the GUI. ~If you change the config value ProcMonitorMethod to "proc" manually in /etc/opensnitchd/default-config.json then it starts working as expected.~

If the daemon is started once the GUI is running, then it starts working as expected.

update: this does not occur with the deb packages, built from latest sources using 1.5.0 branch (also without the ebpf modules, and procMonitorMethod set to "ebpf".

pnavinash commented 1 year ago

Thanks @gustavo-iniguez-goya . I manually edited /etc/opensnitchd/default-config.json to change ProcMonitorMethod to proc. Had to do a restart of opensnitchd before it started working and could change back to ebpf.

Based on your latest edit, it seems like some sort of race condition and editing is not really relevant. I'll do a restart now and check.

Update after reboot: daemon again fails to connect to UI and needs a systemctl restart.

gustavo-iniguez-goya commented 1 year ago

A daemon compiled from sources works as expected in all cases: starting the daemon having the GUI running, starting the daemon before the GUI is running and then launching it. Just in case someone wants to test it out: opensnitchd.gz Or compile it from the 1.5.0 branch.

Arch's opensnitch-1.5.5 daemon fails to connect to the GUI if the GUI is launched once the daemon is running. If the GUI is launched before the daemon then it works. No idea why, we haven't changed any part of the daemon or GUI that affects this functionality.

I'll keep analyzing this problem, but it'd be worth investigating what has changed on Arch opensnitch 1.5.5 vs Aur opensnitch

weltenwort commented 1 year ago

The PKGBUILD seems to patch the versions of quite a few golang packages like grpc:

https://github.com/archlinux/svntogit-community/blob/packages/opensnitch/repos/community-x86_64/fix-go-modules.patch

That could change the behavior of the compiled binary.

gustavo-iniguez-goya commented 1 year ago

ha! good catch @weltenwort .

I can tell that we're compatible with gopacket v1.1.19, but no idea about fsnotify v1.6 (it shouldn't be a problem), netlink v1.1.0 (I don't think it'll cause any problem) and >> gRPC v1.52.3 <<

I'd blame gRPC 1.52.3 based on the history of issues we've had.

user52318908 commented 1 year ago

Any thoughts on when this may be fixed?

gustavo-iniguez-goya commented 1 year ago

This is not an OpenSnitch problem as far as I can tell. But an incompatibility with one of the libraries changed here: https://github.com/archlinux/svntogit-community/blob/packages/opensnitch/repos/community-x86_64/fix-go-modules.patch

weltenwort commented 1 year ago

:information_source: the packaging bug is tracked in https://bugs.archlinux.org/task/77412

famewolf commented 1 year ago

Anybody got a link to a binary that uses the original community PKGBUILD or other workaround?

stasadev commented 1 year ago

The current workaround is to build from source:

git clone https://aur.archlinux.org/opensnitch.git
cd opensnitch
# change the version to 1.5.5 so that pacman doesn't try to replace it with the broken 1.5.5 from the community
sed -i 's/^pkgver=.*/pkgver=1.5.5/' PKGBUILD
updpkgsums
makepkg -si
famewolf commented 1 year ago

Thank you!

grawlinson commented 1 year ago

Yo, Arch Linux packager here. I just got back from holiday so I should have some time soon to fix my overzealous attempt at renovating the go module issues.

famewolf commented 1 year ago

I did build 1.5.3 from source and it works for the most part. I did note that if I click on a tab other than events and then go back to events it no longer populates even though popups continue to occur for new traffic and it appears to continue to work. Possibly just a gui display issue because closing the opensnitch gui and re-opening it causes the events to once again display as expected. I did have to do a systemctl enable and start of the opensnitchd service to get things going.

grawlinson commented 1 year ago

As stated on our bugtracker:

I'm pretty sure I've fixed it, but I would really appreciate it if everyone tested the new package

It should be hitting the repos in the next few hours, please wait a moment for it to propagate through the mirrors.

Apologies to all these that were affected.

weltenwort commented 1 year ago

Version 1.5.7-1 of the opensnitch community package on Arch Linux indeed fixed it for me. Not sure when or if that'll propagate to Manjaro, though.

pnavinash commented 1 year ago

1.5.7-1 fixed it for me too. I'm on Manjaro testing and the package rolled out for me this evening. You can check the status versions of packages in various channels on Manjaro here - https://packages.manjaro.org/?query=opensnitch

Thank you to @grawlinson for the quick packaging fix and to @gustavo-iniguez-goya for being so patient when the issue was reported here and for the fantastic work you're doing on opensnitch.

gustavo-iniguez-goya commented 1 year ago

ok, fantastic news! thanks all

gustavo-iniguez-goya commented 1 year ago

By the way, the daemon is not stopped upon uninstallation (for both opensnitch and opensnitch-git packages):

 ~ $ sudo pacman -R opensnitch                                                                                       1 ✘ 
checking dependencies...

Packages (1) opensnitch-1.5.5-1

Total Removed Size:  14.46 MiB

:: Do you want to remove these packages? [Y/n] 
:: Processing package changes...
(1/1) removing opensnitch                                                     [############################################] 100%
:: Running post-transaction hooks...
(1/4) Reloading system manager configuration...
(2/4) Arming ConditionNeedsUpdate...
(3/4) Updating icon theme caches...
(4/4) Updating the desktop file MIME type cache...
 ~ $ pgrep opensn -a                                                                                                  
2004 /usr/bin/python /usr/bin/opensnitch-ui
2037 /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules
 ~ $ ls -l /usr/bin/opensnitchd                                                                                       
ls: cannot access '/usr/bin/opensnitchd': No such file or directory

This can lead to errors if the user installs the package again (for example if they switch between git and non git version). The new daemon won't start with the error: [2023-02-15 09:59:16] !!! Error while creating queue #0: Error binding to queue: operation not permitted