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 reuming 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.

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.

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:

• provide opensnitchd API via websocket
• provide gRPC-Web server
• simple UI coded in JS/HTML/CSS

Much easier to code high quality interfaces, more contributors available to help like myself. Start by making existing API available via websocket gRPC-Web and making the interface is easy from there

[Foosec]

This will probably be a pretty split opinion, in general i prefer my desktop apps not to have web interfaces due to:
Slower, bloated, often actually uglier, and i have to open my entire browser to use it.
I don't think it would be a necessarily bad feature to but not to replace the native UI with! Maybe to use with servers

Perhaps tho Opensnitchd could provide a dbus interface which could then just be adapted via a little webserver to get a web interface, would leave it open for either implementation!

[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. I will have to look into that. I am Web app developer so web UI is my preference. Maybe keep that option in mind as you make updates. The python/qt is out of my skill set