- Added cli option -config-file to specify an alternate path to the
config file.
- Allow to configure rules path from the configuration file (cli option
takes precedence).
- Default options are now /etc/opensnitchd/rules and
/etc/opensnitchd/default-config.json. Previously the default rules
directory was "rules" (relative path).
Closes#449
- Fixed several leaks.
- Cache of events reorganized and improved.
* items are added faster.
* proc details are rebuilt if needed (checksums, proc tree, etc)
* proc's tree is reused if we've got the parent in cache.
rel: #413
Sometimes we receive /proc/self/exe as the path of the process (electron
apps).
Since a couple of systemd versions ago, some processes spawned by
systemd are reported as /proc/self/fd/<number>.
In these cases reading the symbolic link /proc/<pid>/exe points to the
file on disk.
Previously after installing the rpm GUI package, we created a symlink to
our .desktop file for all users, under /home/*/.config/autostart/
If the path didn't exist we created it, unfortunately as root, which
caused some problems with other applications like Gnome Tweaks.
Now a link is created under /etc/xdg/autostart/, which is what we use
with the debian packages.
Closes: #1068
If the path of the process starts with /tmp/.mount, it typically
indicates that the application is an AppImage.
These apps create a random directory under /tmp, with the pattern
/tmp/.mount_<appId>XXXXXX, where the AppImage is mounted (it's not
always the case, but it usually is).
a0373541c1/runtime.c (L202)
The problem is that if you allow the path to the executable, the next
time you launch the AppImage, the path won't match the rule, and you'll
be prompted again to allow the outbound connection.
So as a helper for the users, if we find the path of the process starts
with /tmp/.mount_, we add an option to the combo box to select the path,
which creates a regular expression to match the AppImage.
Requested here: #1066, #543, #408
When the checksum of a binary changes, due to an update or something
else, you'll be prompted to allow the outbound connection if the
previous checksum of the rule doesn't match the new one.
Without a visual warning was almost impossible to know what was going
on. Besides, you had to dismiss that pop-up, find the rule, and update
the checksum.
Now there's a warning message, and you can update the rule from
the pop-up.
Related: #413
When cloning a rule, or applying a rule to a node, if the rule was of
type List (had multiple operators), the operators were not saved to the
DB.
Closes: #1027
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.
Not deleting events from in-memory db can lead to a high mem usage under
certain scenarios.
Previous attempt to solve this issue wrote events to disk in a temporal
file (when using file::memory:?cache=shared).
Related issues: #844#857Closes: #1030
- Fixed painting rows while scrolling using the mouse.
Sometimes blank lines were inserted at the bottom of the views when
scrolling with the mouse.
- Avoid to rerepaint rows when switching views or scrolling.
- Selecting a row marks it for tracking, ensuring it's deselected when
the row is not visible, and reselected when the row becomes visible
during scrolling.
The following behaviour has not changed:
- Selecting a row that was previously selected, deselects it.
- Keyboard navigation.
Not fixed yet:
- Selecting all the rows of a view with the mouse, visibles and not visibles.
- Entering into a detailed view, going back to the previous view, and
select (restore) the row that was previously selected (causes a
segfault in a particular case).
Related: #1037
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
