In old libnetfilter_queue libs, we can't know the UID of the packet
because the function nfq_get_uid is not present.
We check it dynamically on run time, but we were doing it wrong, so the
daemon didn't run with old libs.
Thaks to Pain-Patate for reporting it in #18.
Processes paths with spaces were not handled correctly.
If the /proc/<pid>/exe link contained the word "(deleted)",
we deleted that part from the process path. But the way we
did it caused to not handle paths with spaces correctly.
Should fix#24
Denied connections were logged with Warning level.
However if you had a rule that denied a particular noisy connection, it
generated too much logs that didn't add value.
In the future it would be nice to log as warning, denied connections
that do not have a rule created by a user.
Discussion: https://github.com/gustavo-iniguez-goya/opensnitch/issues/10#issuecomment-615854975
(1/2)
We start receiving notifications from the UI, which allow us to change
configurations and perform actions on the daemon.
The concept of Node has also been introduced, which identifies every
daemon (client) connected to the UI (server).
These options has been added:
- Enable/Disable firewall interception (for all nodes)
- Change daemons (clients) configuration. globally or per node.
- Change prompt dialog options.
We have fixed some bugs along the way:
- Close audit client connection gracefully.
- Exclude our own connections from being intercepted.
- Better handling of client connection status with the UI.
We probably has also introduced some other bugs (not listed here).
- Dump connections from kernel querying by source port + protocol.
- Prioritize responses which match the outgoing connection.
- If we don't get any response, apply the default action configured in
/etc/opensnitchd/default-config.json
--
A connection can be considered unique if:
protocol + source port + source ip + destination ip + destination port
We can be quite sure that only one process has created the connection.
However, many times, querying the kernel for the connection details by
all these parameters results in no response.
A regular query and normal response would be:
query: TCP:47344:192.168.1.106 -> 151.101.65.140:443
response: 47344:192.168.1.106 -> 151.101.65.140:443, inode: 1234567, ...
But in another cases, the details of the outgoing connection differs
from the kernel response, or it even doesn't exist.
However, if we query by protocol+source port, we can get more entries, and
somewhat guess what program opened the outgoing connection.
Some examples of querying by outgoing connection and response from
kernel:
query: 8612:192.168.1.5 -> 192.168.1.255:8612
response: 8612:192.168.1.105 -> 0.0.0.0:0
query: 123:192.168.1.5 -> 217.144.138.234:123
response: 123:0.0.0.0 -> 0.0.0.0:0
query: 45015:127.0.0.1 -> 239.255.255.250:1900
response: 45015:127.0.0.1 -> 0.0.0.0:0
query: 50416:fe80::9fc2:ddcf:df22:aa50 -> fe80::1:53
response: 50416:254.128.0.0 -> 254.128.0.0:53
query: 51413:192.168.1.106 -> 103.224.182.250:1337
response: 51413:0.0.0.0 -> 0.0.0.0:0
Added ProcMonitorMethod, which can be "proc", "ftrace" or "audit".
Parameters passed by command line take prevalence over default
configuration.
breaking changes: config options changed from xx_yy to XxYy.
Config example:
{
"DefaultAction": "allow",
"DefaultDuration": "once",
"InterceptUnknown": true,
"ProcMonitorMethod": "audit"
}
