Bug#1037006: opensnitch: Upstream change enables ebpf compilation

[Pijgn]

Package: opensnitch
Version: 1.5.8.1-1+b2
Severity: wishlist
Tags: upstream

Dear Maintainer,

OpenSnitch in Debian is currently incompatible with (some?) kernel space
network tools such as wireguard and NFS. These are entirely unusable so
long as the opensnitchd service is running. An eBPF module is required
when the user does not wish to completely block such traffic, but until
recently the upstream build process could not be included in Debian. [0]

The following information may be helpful for determining whether this
change is small enough to include in a bookworm point release.

I have confirmed this works with the package version mentioned above.
Any new files are from the tree at commit 11baad0. [1]

- Replace "ebpf_prog/Makefile" with the newer file and delete unknown
targets (" opensnitch-procs.o opensnitch-dns.o") on line 30.
- Remove "ebpf_prog/file.patch" since it is no longer needed.
- Add directory "ebpf_prog/bpf_headers" containing 4 upstream files.
- Rename "ebpf_prog/bpf_headers" to "ebpf_prog/bpf" for compatibility.

With the appropriate linux-headers package installed, it should now be
possible to run 'make' in the "ebpf_prog" directory and copy the
resulting "opensnitch.o" file to "/etc/opensnitchd/". (The non-standard
location is fixed upstream and will be deprecated in a future release.)

[0] https://people.skolelinux.org/pere/blog/tags/opensnitch/
[1] https://github.com/evilsocket/opensnitch/tree/
11baad083d5396f4d30af5ce5b1ae6ad80bb5478


-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages opensnitch depends on:
ii libc6 2.36-9
ii libnetfilter-queue1 1.0.5-3
ii libnfnetlink0 1.0.2-2

Versions of packages opensnitch recommends:
ii python3-opensnitch-ui 1.5.8.1-1

[Petter Reinholdtsen]

[Pijgn]

> OpenSnitch in Debian is currently incompatible with (some?) kernel space
> network tools such as wireguard and NFS. These are entirely unusable so
> long as the opensnitchd service is running.

I use opensnitch with NFS on Debian Bookworm, and have not noticed it is
making NFS unusable. How did you end up with this conclusion?

I had problems with UDP traffic and Minecraft earlier, as seen in
<URL: https://github.com/evilsocket/opensnitch/issues/813 >, but managed
to get it working by enabling 'Debug invalid connections' in the Nodes
tab of the preferences. Perhaps it can help you with NFS too?

When that is said, I would very much like to see ebpf support in Debian.
I know upstream is working on figuring this out and that patches would be
most welcome. Perhaps you can provide some?

--
Happy hacking
Petter Reinholdtsen

[Pijgn]

[Petter Reinholdtsen]

> I use opensnitch with NFS on Debian Bookworm, and have not noticed it
> is making NFS unusable. How did you end up with this conclusion?

I may be in error here. Having personally confirmed that wireguard was
broken by the default opensnitch configuration in Debian, I only assumed
that NFS would be equally affected by the missing eBPF module. [0]

> I had problems with UDP traffic and Minecraft earlier, as seen in
> <URL: https://github.com/evilsocket/opensnitch/issues/813 >, but
> managed to get it working by enabling 'Debug invalid connections' in
> the Nodes tab of the preferences.

With the default setting to use eBPF monitoring, the option to 'Debug
invalid connections' has no effect unless /etc/opensnitchd/opensnitch.o
exists. Since the eBPF method requires this module to achieve parity
with proc monitoring, an alternative to patching the build process would
be an emergency change of that default before the Debian 12 release.

> When that is said, I would very much like to see ebpf support in
> Debian. I know upstream is working on figuring this out and that
> patches would be most welcome. Perhaps you can provide some?

My initial bug report lists what I believe to be the minimum changes
that need to be ported from upstream to enable drop-in eBPF support for
our current version. If these changes are small enough to eventually
include in bookworm then it would definitely be worth patching.

Otherwise, the proc method should be made the default for this release
and eBPF considered unsupported in Debian until opensnitch 1.6.0+.

[0] https://github.com/evilsocket/opensnitch/pull/513

[Petter Reinholdtsen]

[Pijgn]

> With the default setting to use eBPF monitoring, the option to 'Debug
> invalid connections' has no effect unless
> /etc/opensnitchd/opensnitch.o exists.

I believe this is a misunderstanding. Even if the default setting is
ebpf, it will fall back to using proc when it fail to find the ebpf
module.

> If these changes are small enough to eventually include in bookworm
> then it would definitely be worth patching.

I believe upstream would be pleased with help with this even if it do
not make it into bookworm.

[Pijgn]

[Petter Reinholdtsen]

> I believe this is a misunderstanding. Even if the default setting is
> ebpf, it will fall back to using proc when it fail to find the ebpf
> module.

My testing suggests this is not reliable with the default eBPF setting.
Applying the 'Debug invalid connections' setting (in the absence of the
module) only produces an error message about the file not existing.

Clicking the Save button allows the option state to persist between
invocations of the settings dialog, but it does not survive a reboot and
wireguard is silently denied regardless. I suppose that could be a bug
against the GUI package; I did not test it headless.

It may be possible to use /etc/opensnitchd/system-fw.json as a
workaround, but I did not try that since I was satisfied with the results
of the procedure outlined at the beginning of this bug report.

> I believe upstream would be pleased with help with this even if it do
> not make it into bookworm.

I think I used the 'upstream' tag wrong. The eBPF build process has
already received a Debian-specific fix upstream, which will be part of
OpenSnitch 1.6.0 when it is released. In this case, any patches would
only be meaningful for bookworm, to exclude unrelated changes.

I am interested in working on the patches to implement this fix, but if
the change will not be compliant with bookworm update policy then the
default monitor should be set to proc instead before it is too late.

[Gustavo Iñiguez Goya]

Hi all,

On Thu, 1 Jun 2023 at 18:25, Pijgn <pi...@riseup.net> wrote:
>
> [Petter Reinholdtsen]
> > I believe this is a misunderstanding. Even if the default setting is
> > ebpf, it will fall back to using proc when it fail to find the ebpf
> > module.
>
> My testing suggests this is not reliable with the default eBPF setting.

Petter is correct: we fall back to proc when ebpf can't be used. There's
no difference in setting it to proc or let it fail.

> Applying the 'Debug invalid connections' setting (in the absence of the
> module) only produces an error message about the file not existing.

The error is "open /etc/opensnitchd/opensnitch.o: no such file or directory"
This causes the settings not to be saved, because the default monitor
method is 'ebpf' and it fails loading the module.

Changing it to 'proc' applies the configuration.

>
> Clicking the Save button allows the option state to persist between
> invocations of the settings dialog, but it does not survive a reboot and
> wireguard is silently denied regardless. I suppose that could be a bug
> against the GUI package; I did not test it headless.

It fails applying the configuration, so the settings are not saved to disk.
Changing the option in /etc/opensnitchd/default-config.json works as expected.

On the other hand, this error only applies to the Node tab. Changing the rest
of the settings (from their respective tabs) works as expected.

>
> It may be possible to use /etc/opensnitchd/system-fw.json as a
> workaround, but I did not try that since I was satisfied with the results
> of the procedure outlined at the beginning of this bug report.
>
> > I believe upstream would be pleased with help with this even if it do
> > not make it into bookworm.
>
> I think I used the 'upstream' tag wrong. The eBPF build process has
> already received a Debian-specific fix upstream, which will be part of
> OpenSnitch 1.6.0 when it is released. In this case, any patches would
> only be meaningful for bookworm, to exclude unrelated changes.
>
> I am interested in working on the patches to implement this fix, but if
> the change will not be compliant with bookworm update policy then the
> default monitor should be set to proc instead before it is too late.
>

The main problem is to decide how the modules should be distributed:
precompiled or compiled on every machine. The latter would add extra
dependencies: clang, llvm, kernel headers, etc.

And as part of the 'opensnitch' package or as a new package?

--

Clave Pública:
gpg --keyserver pgp.rediris.es --recv-keys BCF6BE9C

[Pijgn]

On Thursday, June 1, 2023 6:22:14 PM EDT Gustavo Iñiguez Goya wrote:
> Petter is correct: we fall back to proc when ebpf can't be used.
> There's no difference in setting it to proc or let it fail.

> The error is "open /etc/opensnitchd/opensnitch.o: no such file or
> directory" This causes the settings not to be saved, because the
> default monitor method is 'ebpf' and it fails loading the module.

> Changing it to 'proc' applies the configuration.

So the only difference between 'ebpf' and 'proc' in Debian right now is
whether 'Debug invalid connections' fails mysteriously when enabled?

> The main problem is to decide how the modules should be distributed:
> precompiled or compiled on every machine. The latter would add extra
> dependencies: clang, llvm, kernel headers, etc.

> And as part of the 'opensnitch' package or as a new package?

If the modules cannot be distributed precompiled, I would expect a
separate Suggested package to depend on any development libraries.

In that case the default method in bookworm should be changed to 'proc'
so that users must explicitly choose 'ebpf' before seeing this error.

[Pijgn]

Control: retitle -1 opensnitch: Explicitly use 'proc' fallback by default
Control: severity -1 minor
Control: summary -1 0
Control: tags -1 - upstream + patch

Debian 12 does not ship the eBPF module required for the upstream default
process monitor method. The 'proc' method is used as an implicit fallback,
but python3-opensnitch-ui refuses to set the InterceptUnknown option when
the module is missing and the 'ebpf' monitor method is nominally selected.

My original bug report was based on ignorance of the fallback behavior.
Since eBPF is currently not used at all, patching the build process to add
the missing module would constitute a feature update. That is obviously
out of the question, so here is a minor patch that fixes the actual bug.

Although this bug is not reproducible unless opensnitch-ui is installed
and running, the file that needs to be changed is part of opensnitch.

[Petter Reinholdtsen]

In experimental there now is a new version of opensnitch buiding a
ebpf module.