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.
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
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
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
- Obtain the process's parent hierarchy.
- Display the hierarchy on the pop-ups and the process dialog.
- [pop-ups] Added a Detailed view with all the metadata of the
process.
- [cache-events] Improved the cache of processes.
- [ruleseditor] Fixed enabling md5 checksum widget.
Related: #413, #406
Now you can create rules to filter processes by checksum. Only md5 is
available at the moment.
There's a global configuration option that you can use to enable or
disable this feature, from the config file or from the Preferences
dialog.
As part of this feature there have been more changes:
- New proc monitor method (PROCESS CONNECTOR) that listens for
exec/exit events from the kernel.
This feature depends on CONFIG_PROC_EVENTS kernel option.
- Only one cache of active processes for ebpf and proc monitor
methods.
More info and details: #413.
