- Minimize the risk of race conditions when we're prompting the user to
allow/deny a connection, while we're still reading proc's environ file.
(this was actually a leak).
- Preallocate the Env map with the expected environ vars.
Some use cases:
- Reject connections initiated by certain paths:
Deny all connections initiated by cron*:
/usr/sbin/cron
/usr/bin/curl
"action": "reject",
"operator: {
"type": "list",
"operand": "list",
"data": "",
"list": [
{
"type": "regexp",
"operand": "process.parent.path",
// /usr/bin/crond , /usr/bin/crontab, ...
"data": "^/usr/(s|)bin/cron"
}
]
}
- Reject or Allow connections of binaries launched by another app:
"action": "allow",
"operator": {
"type": "list",
"operand": "list",
"data": "",
"list": [
{
"type": "simple",
"operand": "process.parent.path",
"data": "/opt/spotify/bin/spotify"
},
{
"type": "simple",
"operand": "process.path",
"data": "/usr/bin/wget"
}
]
}
You can also combine multiple parent paths, to allow a command launched
from a specific chain of processes:
/usr/lib/systemd/systemd
/usr/sbin/cron
/bin/sh
/usr/bin/curl
The order is checked from the newest process to the oldest (curl -> sh
-> cron -> systemd)
The operand can be used with any of the existing types (simple, regexp,
etc).
Related: #406
Disabled rules were part of the active rules. The fields were not
evaluated, but we still went through the entire list.
Not adding them to the list of active rules improves matching time,
especially when there're a lot of disabled rules.
It mainly affected when matching rules that were non-priority or
ordered alphabetically, with action Allow.
- daemon: Allow to dump XDP sockets from kernel.
- ui: Added options to filter by RAW protocol and AF_XDP family.
- Bumped vishvananda/netlink version to v1.3.0.
- Updated go.mod and go.sum
Sometimes we may receive a connection event after the exit of a
process:
[exec] /bin/xxx, pid 1234
[exit] /bin/xxx, pid 1234
[new conn] pid 1234 -> process unknown (on exec event and no /proc entry)
In these scenarios, we delay the deletion from cache a little
bit, to keep the PID available for a longer time.
There was a situation where if the ebpf modules path did not exist,
the fw rules were not added, causing the daemon to crash after
connecting to the GUI.
When the Process Connector is used to intercept exec events, get and
build the process tree of a process.
PROCESS CONNECTOR feature was added here: 7a9bb17829
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.
- Calculate the ram usage of a process in the daemon, using the page
size of the system.
- Added new functions to read some details of a process, so we can use
them in other parts of the code.
Added new task to monitor the resources of remote nodes, like
ram, swap, number of processes or load average of the system.
The task is initiated when the user selects a node, and the data
received from the node is added to the right panel of the Nodes tab.
The task is stopped when changing to another tab, or when deselecting a
node.
Particularly useful for monitoring remote nodes.
daemon tasks are actions that are executed in background by the daemon.
They're started from the GUI (server) via a Notification (protobuf),
with the type TASK_START (protobuf).
Once received in the daemon, the TaskManager starts the task in
background.
Tasks may run at interval times (every 5s, 2days, etc), until they
finish an operation, until a timeout, etc.
Each task has each own configuration options, which will customize the
behaviour of its operations.
In this version, if the GUI is closed, the daemon will stop all the
running tasks.
Each Task has a flag to ignore this behaviour, for example if they need
to run until they finish and only send a notification to the GUI,
instead of streaming data continuously to the GUI (server).
- Up until now we only had one task that could be initiated from the GUI:
the process monitor dialog. It has been migrated to a Task{}.
- go.mod bumped to v1.20, to use unsafe string functions.
- go.sum updated accordingly.
When exporting rules from the GUI, the Created field was exported as
timestamp. Importing rules worked fine, because json.Marshall() accepts
the timestamp format.
However, when the daemon was loading a rule with the Created field as
timestamp, since the field was defined as time.Time, it expected a RFC3339
string (https://pkg.go.dev/time#Time.UnmarshalJSON)
so it failed to parse the timestamp and the rule was not loaded.
Now the field is defined as string, it's always saved as RFC3339, and if
we fail to parse these fields we'll use a temporary date instead of
failing loading the rule.
More info:
https://github.com/evilsocket/opensnitch/issues/1140#issuecomment-2140904847Closes#1140
Start monitoring the config file every time we read the file, to survive:
- malformed json file
- intermediate file removal (when writing we receive 2 write events,
one of0 bytes)
"A watch will be automatically removed if the watched path is deleted or
renamed"
"A path can only be watched once; watching it more than once is a no-op and
will not return an error"
https://pkg.go.dev/github.com/fsnotify/fsnotify#Watcher.Add
- When reloading rules from a path:
stop existing (domains,ips,regexp) lists monitors, stop rules
watcher and start watching the new dir for changes, delete existing
rules from memory, etc.
- Previously, cli parameters (queue number, log file, etc) were taking
into account before loading the configuration.
Now the configuration file is loaded first (default-config.json), and
if any of the cli parameter has been specified, it'll overwrite the
loaded configuration from file.
This means for example that if you use "-process-monitor-method proc",
and "ebpf" is configured in default-config.json, firstly "ebpf" will
be configured, and later "proc".
(-queue-num option for now requires to match config option
cfg.FwOptions.QueueNumber)
Allow to customize:
- EventsWorkers: number of goroutines to handle kernel events.
Default 8.
- QueueEventsSize: max number of events in the queue.
By default 0, meaning that it'll relay on the available goroutines to
process the events. If it's > 0, and the daemon can't process the
events fast enough, they'll be queued. Once the queue is full, it'll
behave as it was of size 0.
If there're lost events, a message will be logged: "Lost ebpf events..."
