Next steps (2025): migrating to cilium/ebpf, port to Qt6

[gustavo-iniguez-goya]

We have two important tasks ahead of us to keep opensnitch up to date.

[ ✔️ ] eBPF

Up until now we've been using https://github.com/iovisor/gobpf/ for intercepting events from the kernel, and it has worked very well.
But unfortunately it's deprecated since 2021 (iovisor/gobpf#304), which means that some of the known issues and limitations won't be fixed:

• When resuming from suspend state, intercepted events are not deleted from the kernel, which causes the maps to be filled up, leading to not be able to intercept or save new events. Also, BPF_MAP_TYPE_PERF_EVENT_ARRAY behaves erratic in this scenario, not sending all the intercepted events to user-space. a7e64b0 unknown process connecting on port 443... ipv6/networkmanager/latest git opensnitch.. systemd-resolved, firefox/firejail? #834 (reply in thread))
• There's no support for BPF_MAP_TYPE_RINGBUF, BPF_LSM and other features. In the short term, support for ringbuffers is interesting because the performance is superior (https://nakryiko.com/posts/bpf-ringbuf/).
• There's an issue in aarch64, where the intercepted events are not sent correctly to user-space.
• It uses a custom bpf_map_def struct to define maps. Not a big deal, but it has risen concerns and doubts among some users.

So after evaluating some options, I've migrated the code from gobpf to github.com/cilium/ebpf.

The results so far are:

• The issue resuming from suspend state is gone.
• It supports all the latest ebpf features, and I guess it'll be kept updated with futures changes.
• There're no issues on aarch64 (there're some issues on i686 and armhf though, that we'll have to investigate or ask for help. Anyway, network interception works in these archs).
• It's a pure Golang library, which in theory should had better performance than gopbf, which uses C bindings.
  (If we also get rid of the libnetfilter_queue library in favor of go-nfqueue, we could be more portable (android, embedded devices, etc.).)
• BPF_MAP_TYPE_RINGBUF is less likely to lose events under high demand.
• Some (hardened) kernels mount debugfs under /sys/kernel/tracing/ instead of /sys/kernel/debug/tracing. We used to fail adding the kprobes in these environments, but with the Cilium lib this is no longer a problem.

More testing is needed, but it looks promising.

---

[ ✔️ ] Qt6

We've been using PyQt5 for the GUI since at least 1.0.x version. But as Qt5 entered EoS some years ago, a lot of distros have started to deprecate it.

The concerning news regarding OpenSnitch is that Ubuntu plans to remove Qt5 from Ubuntu 25/26 https://discourse.ubuntu.com/t/removing-qt-5-from-ubuntu-before-the-release-of-26-04-lts/49296 , https://www.phoronix.com/news/Ubuntu-Hopes-Removing-Qt-5.

Probably other distros will remove it earlier. NixOS for example asked to port the GUI to Qt6 some time go.

This means, that it won't be possible to install the OpenSnitch GUI on old distros, like LinuxMint 17 to 21, Ubuntu 16 to 22 ... unless you install PyQt5 manually via pip. Or well, we make the GUI compatible with PyQt5 and PyQt6.

There's no estimation for this task yet. Done: e5d1702

https://www.pythonguis.com/faq/pyqt5-vs-pyqt6/

[NRGLine4Sec]

Great news for OpenSnitch futur !

Will the move to cilium/ebpf make it easier to dump the connection to a PCAP or tshark terminal ? ([Feature Request] Add the possibility to dump the connection to a PCAP · Issue #557 · evilsocket/opensnitch)

[gustavo-iniguez-goya]

Not really @NRGLine4Sec . But I added this feature with that request in mind, which should ease to add that functionality (I know I know, the request is super old but I don't forget about it).

Now it'd be really easy to send a task (RECORD_PCAP) to the daemon, with parameters like file, filters, duration maybe.. and once it finishes or the user stops it, the daemon would send a notification to the GUI with the size and file.

Displaying the traffic in real-time in the GUI would be a different thing.

[Foosec]

Hello, ive been trying to package it for openSUSE and found lots of problems with aging protobuf dependencies.
Maybe we can have a whack at that too? I can help

[Foosec]

Sorry, i missed this notification.
It seems that the latest protoc-gen-go-grpc produces code incompatible with the current codebase.
go.mod also lists go1.17 which is pretty old by now :)

Bumping the go version to get around those errors raises new issues.

[   16s] + make opensnitch_daemon
[   16s] make[1]: Entering directory '/home/abuild/rpmbuild/BUILD/opensnitch-1.6.6/daemon'
[   25s] # github.com/evilsocket/opensnitch/daemon/ui/protocol
[   25s] ui/protocol/ui.pb.go:2537:31: undefined: any
[   25s] ui/protocol/ui.pb.go:2632:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2644:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2656:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2668:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2680:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2692:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2704:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2716:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2728:47: undefined: any
[   25s] ui/protocol/ui.pb.go:2728:47: too many errors

[gustavo-iniguez-goya]

aah, yeah. I think "any" was introduced in go1.18.

Anyway go.mod version does not forces to use go1.17, it's the minimum version to use. If you compile it with >= go1.18 should compile fine.

The other option is to install a grpc/protobuf versions supported by go1.17.

You can either download go from their web or install grpc/protobuf versions from golang repositories. Or do you need to compile it with the versions shipped with OpenSuse x.y?

[Foosec]

Sadly bumping the Go version introduces other issues
ui/protocol/ui.pb.go:2537:31: predeclared any requires go1.18 or later (-lang was set to go1.17; check go.mod)

Using an older protoc-gen-go-grpc would probably work, but im not sure exactly which one that would then be?
That is to say, with the current build instructions in the wiki, it does not build :)

I've tried creating a seperate package for protoc-gen-go-grpc with Ubuntu 20.04 sources specifically to compile this, with different errors.

Im not sure how much work it would entail, but it seems to me the cleanest thing to do is to bring the dependencies up to slightly newer version?

How are the current RPM's in releases built?

[gustavo-iniguez-goya]

Try installing these versions:

go install google.golang.org/protobuf/cmd/[email protected]
go install google.golang.org/grpc/cmd/[email protected]
apt install protobuf-compiler

I've tested it in Ubuntu 22.04 with go-1.17 and compiled fine. If go-1.17 is available in ubuntu 20 it should compile fine as well.
If it's not, you can use a newer go:

curl https://go.dev/dl/go1.21.7.linux-amd64.tar.gz -o go1.21.7.linux-amd64.tar.gz
tar -C /usr/local/ -zxf go1.21.7.linux-amd64.tar.gz
export GOPATH=/usr/local/go
export PATH=$GOPATH/bin:$PATH

comments at the top of the generated protobuffers:

• ui_grpc.pb.go

  // Code generated by protoc-gen-go-grpc
  // versions:
  // - protoc-gen-go-grpc v1.3.0
  // - protoc             v3.12.4
  

• ui.pb.go

  // Code generated by protoc-gen-go
  // versions:
  // - protoc-gen-go v1.32.0
  // - protoc        v3.12.4
  

How are the current RPM's in releases built?

rpms are built in a Debian 11, like the deb packages. The reason is mainly for compiling against a libc that is compatible with old distros.

[Foosec]

Thank you for the help! The versions were helpfull.
I've built the Daemon, now onto the UI :)

[e3dio]

Any thoughts on switching from QT/Python to Web based UI interface, similar to @evilsocket https://github.com/bettercap/bettercap and many other Web based UI tools

• OpenSnitch provides a documented gRPC server
• Web UI using gRPC-Web grpc-gateway

Much easier to code high quality interfaces, more contributors available to help like myself

[gustavo-iniguez-goya]

Personally I also prefer a desktop app. Some apps besides a GUI offer a web based interface (transmission or amule for example).

In the case of OpenSnitch maybe is a bit different. The daemon should not have any UI, and act as an independent agent that logs everything to a remote server (a GUI, TUI, whatever). This is how pretty much this kind of apps work (grafana, auditd / go-audit, etc)

The GUI in reality is composed of 2 components: a gRPC server which communicates with the daemons, and the Qt GUI.
Currently the server is integrated with the GUI, but it could be a separate package or process that had different kinds of UIs (TUI, GUI, web interface...).

Similar to this: https://github.com/gustavo-iniguez-goya/opensnitch/tree/cli/server

For the time being, I want to release the v1.7.0 ASAP, migrate to cilium, refactor the main GUI window and port the GUI to Qt6. And eventually publish a TUI. It'd be cool if we could use https://github.com/opensnitch repo to group all the tools.

[e3dio]

Looks like there is gRPC-Web to create web based interface with existing gRPC server

[e3dio]

The GUI in reality is composed of 2 components: a gRPC server which communicates with the daemons, and the Qt GUI.
Currently the server is integrated with the GUI, but it could be a separate package or process that had different kinds of UIs (TUI, GUI, web interface...).

I made a nice web UI that filters traffic with NF-queue on a Node.js daemon. The key thing OpenSnitch does is determine which application/process created the network connection via eBPF. If you provide documentation for the new gRPC server I will happily provide a nice optional open source web UI, or anyone could provide TUI, Python UI, web UI, etc

[gustavo-iniguez-goya]

great @e3dio ! I'm very interested in creating a new server, and offering a TUI + web UI.

I'll try to update and publish the existing code the next week, at least to start working on it.
The server and the TUI is functional for the v.1.6.x branch.

Adding an HTTP API with https://github.com/grpc-ecosystem/grpc-gateway should be easy.

[e3dio]

I like the grpc-gateway idea, that greatly simplifies UI development by using universal http requests, removes the need for dependency on gRPC-Web which also needs envoy on the server, those are large complex projects. grpc-gateway does seem pretty easy to generate Http server from the gRPC proto. If an Http server is provided anyone can create nice UI with a variety of methods

[Damglador]

Is there any progress on porting to Qt6?

[gustavo-iniguez-goya]

yes @Damglador , some updates here: #1009 . I just need to do some more tests.

[gustavo-iniguez-goya]

GUI finally ported to PyQt6: e5d1702

It should work just fine, I haven't tested the commit on Arch yet.
By the way, the PKGBUILD needs qt6-svg as dependency, otherwise the icons are not loaded.

[allergicapple]

On a sidenode, maybe look a the PKGBUILD of opensnitch-git as there are some patches, maybe something is able to be upstreamed.

[gustavo-iniguez-goya]

Thank you @allergicapple for the feedback!! the ebpf modules should work regardless of the GUI. The GUI only displays the notification received from the daemon.

[allergicapple]

I just stopped, updated and restarted the service; maybe there is just a small version mismatch or something didn't come up correctly. Focus for me was on Qt6, the rest is a task for the package creators :) (btw, Big Thanks to you, too)
Notifications work, too :P

One small thing I noticed is the Firewall dialog which opens when clicking the "Shield" icon in the top row has a empty named tab or something, at least there is a small tab at the bottom of the dialog, which looks off.
Also, there are some trailing spaces in the makefiles and other places. Maybe a Linter could help you with that.

Other than that I'm looking forward to 1.7.3

[XZVB12]

great news. I also wanted to test this change, but unfortunately I couldn’t build git version. All dependencies are installed.

ui/protocol/ui_grpc.pb.go:19:16: undefined: grpc.SupportPackageIsVersion9
ui/protocol/ui_grpc.pb.go:36:68: undefined: grpc.BidiStreamingClient
ui/protocol/ui_grpc.pb.go:49:41: undefined: grpc.StaticMethod
ui/protocol/ui_grpc.pb.go:59:41: undefined: grpc.StaticMethod
ui/protocol/ui_grpc.pb.go:69:41: undefined: grpc.StaticMethod
ui/protocol/ui_grpc.pb.go:78:86: undefined: grpc.BidiStreamingClient
ui/protocol/ui_grpc.pb.go:89:36: undefined: grpc.BidiStreamingClient
ui/protocol/ui_grpc.pb.go:108:21: undefined: grpc.BidiStreamingServer
ui/protocol/ui_grpc.pb.go:129:49: undefined: grpc.BidiStreamingServer
ui/protocol/ui_grpc.pb.go:215:36: undefined: grpc.BidiStreamingServer
ui/protocol/ui_grpc.pb.go:69:41: too many errors

will wait for 1.7.3 release

[LordGrimmauld]

I just went and did the nix build for the new dev versions of opensnitch. Seems to work just fine, wayland-native and icons and everything 🎉

Update draft in NixOS/nixpkgs#435841, waiting for a 1.7.3 release before undrafting that.

[rakbladsvalsen]

Hey @gustavo-iniguez-goya , I just stumbled upon this thread about future plans for opensnitch, and I was wondering: have you considered, or are there any future plans to migrate off of Go?

I've been using opensnitch for ~1 year until now and so far so good. However, I've noticed it consistently uses CPU (not a whole lot, like 2-3% per core - 12th gen Intel CPU) even while doing nothing and I was thinking that, perhaps a complete rust rewrite of the daemon could significantly increase performance and reduce resource usage. I am pretty sure the background usage is caused due to go's GC but alas, there's no way to get rid of it without getting rid of go.

I have plenty of experience using Rust professionally so I'm wondering if you're open to migrating the whole thing to a more modern a performant language? I am more than willing to become a part-time contributor to do so.

[evilsocket]

I'd be 100% down jumping back into this project in the case of a Rust rewrite. The eBPF part would benefit from it as well https://github.com/aya-rs/aya