We track new processes execution by intercepting the enter and exit
of the functions, but sometimes the exit hook is not called, so the
corresponding entry was not being removed from the map.
In this situation the map becomes full and accepts no new entries.
Now the entry is deleted from the map once the process exits, if it
still exists in the map.
By default load the system fw config file from
/etc/opensnitchd/system-fw.json.
There're these options to specify the file to load:
- via cli option with -fw-config-file
- writing it in the default-config.json file:
"FwOptions": { "ConfigPath": "..." }
If both options are empty, then the default one is used.
FIXME:
When the cli option is used to load the fw configuration, and the main
preferences are saved, the fw is reloaded but the path to the fw config
is lost.
On this test we assumed that there would always be reading stats for our
own process /proc/self, but on restricted environments that might not
alwys be the case. Anyway, a value of 0 is not an error in itself.
Closes#1075
We were not deleting DNS entries from the hash map, so when it reached
the maximum capacity (12k entries), we couldn't allocate new entries,
resulting in events not being sent to userspace.
New option to save and display alerts/events received from the daemon,
like system fw errors or eBPF modules errors.
Until now we only displayed a desktop message, making it difficult to
review the message in detail, or other actions.
Now it's possible to configure eBPF modules path from the
default-config.json file:
"Ebpf": {
"ModulesPath": "..."
}
If the option is not provided, or if it's empty, we'll keep loading from
the default directories:
- /usr/local/lib/opensnitchd/ebpf
- /usr/lib/opensnitchd/ebpf
- /etc/opensnitchd/ebpf (deprecated, will be removed in the future).
Closes#928
- Allow to configure system firewall configuration file path:
* via cli (-fw-config-file).
* via global configuration file.
- Allow to configure fw rules check interval.
The system fw config file contains regular iptables/nftables rules.
Previously it was hardcoded to /etc/opensnitchd/system-fw.json
The interval to check if the interception rules were added was also
hardcoded to 10 seconds. Now it's possible to configure it.
A value of "0s" disables the interval, while "" defaults to 10 seconds.
Up until now, the GUI was refreshed if:
- it was not minimized or hidden.
- if there were new events (even if we received events from the daemon,
they were filtered out if they were duplicated).
But still, there were scenarios where refreshing the views every second
(more or less) was too much, like when monitoring multiple machines.
Now it's possible to configure the views' refresh interval, regardless
of what the daemon sends.
Asked here: #1073
- 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
