- 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
BPF_MAP_TYPE_PERCPU_ARRAY was introduced in kernel version 4.6, so with
latest changes to intercept processes we lost support for older kernels
< 4.6.
Now we work again for example on kernels 4.4.
* 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.
Make use of kernel macros to decide for what architectures we compile
the modules.
On armv7l the connections module was failing due to iptunnel_xmit, so
exclude it from being compiled.
One can export ARCH=arm, ARCH=i386 or ARCH=arm64 to compile the modules
for these architectures, instead of hacing to edit the source files.
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.
