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/protoc-gen-go@v1.32.0
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.3.0
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 :)