Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Not blocking internet access if opensnitch isn't running #884

Closed
t3dium opened this issue Mar 20, 2023 · 5 comments
Closed

[Bug] Not blocking internet access if opensnitch isn't running #884

t3dium opened this issue Mar 20, 2023 · 5 comments
Labels
feature a whole new feature

Comments

@t3dium
Copy link

t3dium commented Mar 20, 2023

If the app crashes or even from a delay in launching at boot, all apps are allowed internet access until opensnitch is opened again, which could open up security issues.

i was also looking around in settings and found an option which seemed to do this:
image
but it didn't work, not sure if this is a bug, or if the option does something else

OS: fedora
Version. 1.6.0 (latest as of now)

potentially related to the bug: couldn't install grpcio==1.16.1 with pip as mentioned in the install guide as it gave segmentation fault's, i instead installed the newest version with pip.

@t3dium t3dium added the feature a whole new feature label Mar 20, 2023
@pizzadude
Copy link

I have grpcio 1.50.0 and grpcio-tools 1.50.0 and it works fine with those, can you try that version?

@gustavo-iniguez-goya
Copy link
Collaborator

Besides trying @pizzadude's suggestion, please, be sure that the value DefaultAction is set to "deny" in /etc/opensnitchd/default-config.json

You can also try a simple test:

Any of the commands should fail. If they don't, please, post the log file /var/log/opensnitchd.log

@gustavo-iniguez-goya
Copy link
Collaborator

If the app crashes or even from a delay in launching at boot, all apps are allowed internet access until opensnitch is opened again, which could open up security issues.

Just set DefaultAction to deny in /etc/opensnitchd/default-config.json. If with that option set to deny apps can still connect to the internet, please, drop a comment with an example and how to reproduce it, and we'll review it.

but it didn't work, not sure if this is a bug, or if the option does something else

I've been reviewing this problem, and the option works fine. But it's a bit confusing, and i'm not sure what's the right thing to do here.

With daemon DefaultAction: allow and GUI DefaultAction: deny:

  • The daemon connects to the GUI and sends its configuration (default-config.json -> Action: allow)
  • The GUI saves the configuration of the daemon in memory, and reconfigures daemon's DefaultAction to deny (because GUI's DefaultAction is deny)
    • Daemon's DefaultAction is only reconfigured in memory, it's not saved to disk.
  • When opening the GUI Preferences, daemon's DefaultAction is set to deny, and that's how it's working while it's running, but /etc/opensnitchd/default-config.json DefaultAction is set to allow.
    So:
    • ^ This may cause some confusion.
    • While the GUI is running the daemon should not allow outbound connections by default. It'll prompt you to deny/allow connections anyway, but if you decide not to use pop-ups it should apply GUI's DefaultAction.

So the question is: GUI's Preferences->Nodes->DefaultAction should reflect the daemon's DefaultAction being used (this is how it works right now), or the one saved in /etc/opensnitchd/default-config.json?

This behaviour was changed here f5bb478 because of this #489

And probably this behaviour should be documented on the wiki.

@gustavo-iniguez-goya
Copy link
Collaborator

gustavo-iniguez-goya commented Apr 15, 2023

Ok, I'll modify the behaviour as follow:

Daemon not connected to the GUI:

  • Use the DefaultAction defined in /etc/opensnitchd/default-config.json

Daemon connected to the GUI:

  • Use GUI's DefaultAction (by default Deny):
    1. For pop-ups
    2. Reconfigure daemon's DefaultAction while it's connected to the GUI. On disconnecting use daemon's DefaultAction.
  • Don't modify nodes' DefaultAction value and save it as is, so it's displayed correctly on Preferences->Nodes.

At least this way the user will clearly see that daemon's DefaultAction is set to allow by default (related #896).

gustavo-iniguez-goya added a commit that referenced this issue Apr 15, 2023
- On the very first install, or if the GUI's settings.conf file was not
  created, GUI's DefaultAction item was not configured properly.
- Now when the daemon is not connected to the GUI, it'll use the
  DefaultAction configured in /etc/opensnitchd/default-config.json
- When the daemon is connected to the GUI, the GUI will reconfigure
  daemon's DefaultAction value when the one defined by the GUI.
  In this case the value defined in default-config.json is not modified,
  it'll only be valid while it's connected to the GUI.

Now when opening Preferences->Nodes, it'll display daemon's
DefaultAction defined in the file default-config.json file, which is the
default action applied when the daemon is not connected to the GUI.

Related: #884 , #896
@gustavo-iniguez-goya
Copy link
Collaborator

closing due to lack of feedback

gustavo-iniguez-goya added a commit that referenced this issue Oct 19, 2024
Nfqueue bypass option skips the enqueue of packets to userspace
if no application is listening to the queue.
https://wiki.nftables.org/wiki-nftables/index.php/Queueing_to_userspace

If this flag is not specified, and for example the daemon dies
unexpectedly, all the outbound traffic will be blocked.

Up until now we've been using this flag by default not to block network
traffic if the daemon dies or is killed for some reason. But some users
want to use precisely this behaviour (#884, #1183, #1201).

Now you can configure it, to block connections if the daemon
unexpectedly dies.

The option is on by default in the configuration (QueueBypass: true).
If this item is not present in the daemon config file, then it'll be
false.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a whole new feature
Projects
None yet
Development

No branches or pull requests

3 participants