On some kernels (4.19), adding the interception rule to the
inet-mangle-output chain failed.
According to the nftables wiki, the mangle-output chain have (must?) to
be of type Route:
"route type: ... mangle table ... for the output hook (for other
hooks use type filter instead)."
https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types
So if we fail adding the interception rule, we retry it with type Filter
instead of Route.
Related: #781 , ced9a24
- Fixed firewall dialog label alignment.
- Fixed potential race condition when stopping the daemon, and there're
connections being enqueued.
- Added "clear" button to GUI's filter line (#786)
- Create ebpf cache object only if the modules have been loaded.
- Set default stats workers to the sme amount defined in configuration.
Closes#785
This is part of latest commit ced9a24933
- When reusing a chain, configure the new policy.
- Don't backup existing rules when reloading the configuration.
On some systems after disabling and enabling the interception, the
DNS rule was not being re-added, with error: chain already exists.
When the interception is disabled, we firstly remove the rules,
and secondly if the chain and table is empty we try to remove them
as well.
However, on some systems even if "nft list ruleset" didn't list the
chains to hold our rules, it failed with error "already exists".
Before adding a chain now we check if it exists, and if it does we
reuse it.
Closes#781
* daemon/Makefile: add support for PREFIX, DESTDIR, SYSCONFDIR in install
This is helpful for package maintainers who need to install components
into specific locations for building packages of this project.
example:
$ make \
PREFIX=/usr \
DESTDIR=/some/package/dir \
SYSCONFDIR=/foo/etc \
install
* daemon/Makefile: use 'install' to copy files / make dirs
Under certain situations, like when using systemd-resolved as DNS
resolver, we receive outbound connections with the fields swapped:
Instead of: local-port:local-ip -> public-ip:public-port
we receive: public-port:public-ip -> local-ip:local-port
Sometimes this behaviour causes network slowdowns, or no network at all.
If we swap the fields of these connections, then we're able to get the
process and keep functioning as usual. But what causes this behaviour is
yet unknown, and needs further analysis.
See these issues for more information: #779 , #711
- Allow to use commas to define conntrack states:
("related,established")
- Remove profile's rules when switching from Deny to Allow.
- Fixed checking duplicated rules.
Closes#778
- Configuration of system firewall rules from the GUI is not supported for
iptables. Up until now only a warning was displayed, encouring to change
fw type manually.
Now if configured fw type is iptables (default-config.json, Firewall:),
and the user opens the fw dialog, we'll ask the user to change it from
the GUI.
- Add fw rules before connecting to the GUI. Otherwise we send to the
GUI an invalid fw state.
In order to detect short-lived processes we intercept new processes
executions as they happen, and cache them for later use.
When a new connection is established, then we check if the PID of the
connection is cached, and use the details of the process to ask the user
to allow or deny it.
However, there're some situations where the path or cmdline of a PID,
doesn't correspond with the one that's establishing the connection.
Given the same PID:
- Sometimes we receive from the tracepoint a wrong/non-existent path.
- Other times we receive a "helper" which is the one executing the
real binary that opens the connection.
For these reasons now when a new connection is established, we read the
path to the binary from proc. If the PID is cached and the cached path
differs, then we'll use the path from proc.
We lose a bit of performance, but hopefully we'll be more consistent
with what the user expect, while at the same time keeping intercepting
short-lived processes.
Downsides: for execveat() executions we won't display the original binary.
Closes#771
Whenever a process exits, we delete the corresponding entry from
cache.
But when a process executes a new process (sh -c ls), we receive an
exit event for the parent, while the child continues working with *the
same PID*. Sometimes we don't receive exit events for the child, so the
entry was never removed from cache.
We should properly detect the exits, but forthe time being, delete
expired processes from cache every minute.
Up until now we loaded the eBPF modules from /etc/opensnitchd.
However there has been some problems upgrading the modules to newer
versions with the deb packages, because every file under /etc/ is
treated as a conffile, and whenever a conffile changes it prompt you to
update it or not. Some users decided to no upgrade it, ending up with
eBPF modules incompatible with the new daemon.
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles
On the other hand, the FHS dictates that /etc/ is for configuration
files, and /usr/lib for object files:
"/usr/lib includes object files and libraries. [21] On some systems,
it may also include internal binaries that are not intended to be
executed directly by users or shell scripts."
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html
So now, we look for the eBPF modules under /usr/local/lib/opensnitchd/ebpf/
or /usr/lib/opensnitchd/ebpf/, and as a last resort under
/etc/opensnitchd/
Up until now some error and warning messages were only logged out to the
system, not allowing the user know what was happening under the hood.
Now the following events are notified:
- eBPF related errors.
- netfilter queue errors.
- configuration errors.
WIP, we'll keep improving it and build new features on top of this one.
Added more options to match connections against packets metainformation:
skuid, skgid, l4proto, protocol
Fixed setting mark on packets via meta (although it results in an error
-> [invalid type]).
If the table family where we're adding a daddr/saddr is inet, we need to
specify the protocol of the IP being added.
Otherwise, listing the rules they appear as:
@nh,128,32 3232235777 accept
instead of: daddr 192.168.1.111 accept
seen here: #704
- Get cmdline arguments from kernel along with the absolute path to the
binary.
If the cmdline has more than 20 arguments, or one of the arguments is
longer than 256 bytes, get it from ProcFS.
- Improved stopping ebpf monitor method.
