Java applications are not noticed by OpenSnitch

[savoury1]

Similar to #171 it appears that Java applications specifically are not noticed by OpenSnitch. The two Java applications tested by me so far with OpenSnitch are Vuze and Jitsi, neither of which generate any UI prompts at all.

After adding -debug to the daemon command line (editing /etc/systemd/system/opensnitchd.service as mentioned in #171), restarting and loading the applications again there is no mention of them in the opensnitchd.log file. DNS lookups that clearly relate to each application can certainly be seen in the debug log, but there is simply no other information in the log mentioning either of the application names or process ids or anything other than DNS lookups.

For many applications OpenSnitch does generate a prompt in the expected fashion, including wget (distinct from comments in #171) and numerous others. So OpenSnitch is somewhat working on my system and this is a great start. Many thanks @evilsocket for your efforts in working to create such a useful firewall tool for Linux systems!

[p-]

I also encountered this issue and did some analyzing. I'm not entirely sure if I came to the right conclusion, but I don't think it is directly connected to Java. The problem seems to be that OpenSnitch has only limited support for the IPv6 stack (which Java uses by default, regardless if is necessary or not).

Here's how you can follow that train of thought:

A simple way to test a Java HTTP Connection (using OpenJDK 10/11):

1. Install OpenJDK sudo apt install openjdk-11-jdk-headless
2. Open the Java REPL by executing $ jshell
3. Inside JShell enter following Java code which makes a HTTP Request to github.com:
4. ((HttpURLConnection) new URL("https://github.com").openConnection()).getResponseCode()
5. This should then return the HTTP status code 200. (OpenSnitch does not ask the user)
6. Leave jshell with /exit.

Following lines were logged:

DBG  New DNS record: 140.82.118.4 -> github.com
DBG  New DNS record: 140.82.118.3 -> github.com
DBG  New DNS record: 140.82.118.4 -> github.com
DBG  New DNS record: 140.82.118.3 -> github.com
DBG  Could not find netstat entry for: 10.0.2.15 ->(tcp)-> github.com:443
DBG  Could not find netstat entry for: 10.0.2.15 ->(tcp)-> github.com:443
DBG  Could not find netstat entry for: 10.0.2.15 ->(tcp)-> github.com:443

If you do the same as above but start JShell with the preferIPv4Stack system property, OpenSnitch works as expected:

$ jshell -R-Djava.net.preferIPv4Stack=true

The code only seems to check /proc/net/tcp but the IPv6 Connections are in /proc/net/tcp6 and contain longer IPv6 addresses.

Two of the things that probably at least have to be changed are:

• FindEntry should be called somehow with tcp6
• hexToIP should support IPv6 addresses
• probably more ...

Apologies, if I'm wrong and thanks for OpenSnitch!

[jkozera]

I've also noticed that IPv6 connections are ignored, however I think I've managed to prepare a patch which fixes that. Preliminary testing suggests that it works, as per the screenshot.

The patch is available at https://github.com/jkozera/opensnitch/commit/b5135bd5cdcd5db0d2a0fd161eca6ac2c695df6b (together with support for UDP broadcasts, and list rules for #151 in the same branch)

[p-]

@jkozera First of: thanks for the IPv6 support!

Second: I tested it and for me the Java/IPv6-Stack bypass still works (as shown in my sample). There seems to be a problem noticing applications that use the AF_INET6 socket for IPv4 connections.

The problem could be that FindEntry is never called with tcp6 in that case.

[m5x]

Same here. Connections from Java applications to IPv4 are not detected. Maybe this issue should be reopened so that it does not look like it is fixed.