We were not matching the end of the domain, which could lead to allow
more domains than expected.
kudos to @FWDekker for reporting this issue.
Details: #1264
Sometimes the source IP of an outbound UDP connection is specified
via ancillary messages, by using IP_PKTINFO or IPV6_PKTINFO.
In these cases the source IP of the sock struct is empty (0.0.0.0,
sk->__sk_common.skc_rcv_saddr).
Now in udp_sendmsg(), if sk->sk_rcv_saddr is empty, we'll try to
extract it from the ancillary message. IPv4 only for now.
Sometimes we failed to retrieve the details of a connection, which
inadvertently caused us to block certain applications (Parsec).
By using inet_dgram_connect() we're now able to identify the PID of
a connection in more cases, such as in #1246.
Note: it's excluded from armhf, since I've been unable to make it work
on that platform.
In some distros like Ubuntu 25, we were not displaying the fw button
icon, which made the button practically hidden to the user.
We assumed that if 'document-new' icon was available, the rest of the
icons would be available as well, so we wouldn't need to fallback to
Qt's builtin icons.
However on Ubuntu 25 for example, despite of 'document-new' being
available, the icon 'security-high' was not being displayed when it was
loaded from the stats.ui file.
Loading it from code with QIcon.fromTheme() works fine, and even if
it's not found (which sometimes happens), we'd fallback to Qt's builtin
icons.
Other icons may be optional, but icons without text need to have an
icon always.
- Added python3-packaging as dependency to load dynamically the
protobuffers (python3-packaging for Fedora, python-rpm-packaging
metapackage for OpenSuse).
- Fixed patching protobuffers.
Protobuffers compiled with protobuf < 3.20.0 are incompatible with
protobuf >= 4.0.0:
https://github.com/evilsocket/opensnitch/wiki/GUI-known-problems#gui-does-not-show-up
This has been a source of problems for some users (#1214, #647), and
in some distributions, previous protobuffer does no longer work due to
incompatibility with the protobuf package version installed
(OpenSuse Tumbleweed).
So in order to solve this issue, we provide several protobuffers,
for old and new protobuf versions:
proto/ui_pb2* for protobuf >= 4.0.0
proto/pre3200/ui_pb2* for protobuf >= 3.6.0 and < 3.20.0
To avoid import errors, each protobuffer must be placed in its own
directory, and the name of the protobuffer files must be named with
the syntax <prefix>_pb2.py/<prefix>_pb2_grpc.py:
ui_pb2.py and ui_pb2_grpc.py
The default compiled protobuffer will be opensnitch/proto/ui_*.py
instead of opensnitch/ui_*.py
Long paths or binary names can misalign the dialog.
In order to prevent this:
- don't allow labels to grow more than the dialog's width.
- if the labels text is larger than max_value, use zero-width space to
allow to split words.
Commands with non-printable characters were misaligning the labels.
Now these characters are exclude from the labels, and texts are
displayed as a single line.
There're only two points where we need to reconfigure the columns:
on showEvent() and when saving the settings.
There should be a slight performance improvement.
Under Wayland the GUI doesn't work entirely well (#733).
Setting QT_QPA_PLATFORM to 'xcb' solves some issues, like correctly
positioning popups, but users had to configure it manually.
Now it's possible to configure it from the Preferences dialog.
Setting it to "" will use the default option of the Desktop Environment.
When there were no nodes connected, we disabled the global fw button
that enables/disables the fw.
Unfortunately when a node connected to the GUI, this button was not
clickable anymore.
(cherry picked from commit aa0d5f14dd)
When disabling the fw, we change the default input and output policy to
Accept, not to block connections.
Due to a problem reloading the fw in the daemon, the policy was not
changed as expected.
This problem must be fixed in the daemon, but for the time being,
sending two configuration changes solves the issue (one for changing the
policy, and another one for disabling the fw).
Closes: #1225
(cherry picked from commit d825f1e9b0)
When a popup was displayed to the user, if they took more than 120s to
respond, the address of the node was lost.
This is because the daemon has hardcoded a max timeout of 120s. If it
fires, the call to AskRule is closed and the context is lost.
In this situation, save the address of the node at the start of AskRule,
so we can reuse it later.
When closing the GUI we were not stopping notifications channel in all
cases, causing some issues (delays, log in/out problems, ...).
Closes#1217
(cherry picked from commit cdf93c72c1)
When creating/editing rules to filter by lists of nets/IPs/domains, we
check if the path entered is a directory.
However on remote nodes, the path may not exist where the GUI is
running, but be valid where the daemon is running.
Now we only check the path if the node where it's being configured is
local.
(61727af788)
Since the name of the rule is used for the file name on the disk,
certain characters caused issues when saving the rule, like '/'.
Now if the user types or pastes '/' in the name field, a warning is
displayed, indicating that some characters are not allowed.
(2e90f3832d)
In b93051026e we disabled sending/parsing
list operators as JSON strings. Instead, now it's sent/parsed as
protobuf Rule, and saved to disk as JSON array, which ease the task of
manually creating new rules if needed.
This change was missing in the previous commit.
(cherry picked from commit 2fc9ed276b)
Previously when creating a new rule we followed these steps:
- Create a new protobuf Rule object from the ruleseditor or the
pop-ups.
- If the rule contained more than one operator, we converted the
list of operators to a JSON string.
- This JSON string was sent back to the daemon, and saved to the
DB.
- The list of operators were never expanded on the GUI, i.e., they
were not saved as a list of protobuf Operator objects.
- Once received in the daemon, the JSON string was parsed and
converted to a protobuf Operator list of objects.
Both, the JSON string and the list of protobuf Operator objects were
saved to disk, but the JSON string was ignored when loading the
rules.
Saving the list of operators as a JSON string was a problem if you
wanted to create or modify rules without the GUI.
Now when creating or modifying rules from the GUI, the list of operators
is no longer converted to JSON string. Instead the list is sent to the
daemon as a list of protobuf Operators, and saved as JSON objects.
Notes:
- The JSON string is no longer saved to disk as part of the rules.
- The list of operators is still saved as JSON string to the DB.
- About not enabled rules:
Previously, not enabled rules only had the list of operators as JSON
string, with the field list:[] empty.
Now the list of operators is saved as JSON objects, but if the rule
is not enabled, it won't be parsed/loaded.
Closes#1047
(cherry picked from commit b93051026e)
