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.
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/
"$XDG_RUNTIME_DIR defines the base directory relative to which user-specific
non-essential runtime files and other file objects (such as sockets,
named pipes, ...) should be stored. The directory MUST be owned by the
user, and he MUST be the only one having read and write access to it.
Its Unix access mode MUST be 0700."
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
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.
Up until now, the daemon communicated with the GUI via a unix socket,
stored in /tmp.
/tmp however can be erased at any time (tmpreaper, systemd-tmpfiles.d),
which may lead to remove our unix socket file, and hence losing
connectiong with the daemon.
Now the user has the option to store the socket file under
/run/user/$uid/opensnitch/
https://www.linuxbase.org/betaspecs/fhs/fhs.html#runRuntimeVariableData
In the future we may switch to this path by default.
Build eBPF modules whenever a change to the modules is pushed.
It'll fail if there're some warnings.
The action compiles *and publishes* the modules for several branches and
kernels.
Hopefully this will help to automate this process and be more transparent.
It'll also help on issues like this one: #454
Added a helper to easily allow inbound connections, just by selecting
the port where a service is listening on.
Especially useful when the inbound policy is drop and you want to allow a
service (ssh, nfs, etc).
