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
(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).
auditd events provides the parent pid of a process which has created
a connection. If we don't find the socket inode under the pid of the
process, use the ppid.
This is normally the case when systemd-* spawns a new process which
creates a new connection.
mozilla/libaudit-go does not support i386/arm/etc, and we were using it
only for parsing audit messages.
So do not use it and parse raw messages directly. WIP.
Use auditd events to keep a list of PIDs which open sockets, reading
them from the audisp af_unix plugin.
- Install auditd and audisp-plugins
- Enable the af_unix plugin (/etc/audisp-plugin/af_unix, active = yes)
- Start opensnitch with -process-monitor-method audit.
If the choosen method is audit but it's not active or not installed,
it'll fallback to /proc anyway.
If it's properly configured, a debug trace will be written to the logs:
"PID found via audit events ..."
Until now OpenSnitch used ftrace(debugfs) to search for running
processes (PIDs) and obtain the process path.
On some systems, this filesystem is not mounted or available, so we have
to rely on /proc.
After several weeks of use, I think that it's faster and more accurate
the 2nd method, search pids/cmdlines in /proc. So we offer the user to
choose which one to use.
Processes with active connections are the most likely to be the latest
modified ones in /proc, thus sort cache pids by time speeds up pids cache
searching. From several ms to us.
When parsing /proc/<pid>/fd/ looking for sockets, latest
modified/created descriptors are the most likely to have
generated connections.
This way we decrease the parsing time, system load and speed up process name
retrieval.
With the current implementation, it's not possible to know what
process/pid has created an outgoing connection, but there's still
valuable information that the user may want to know, so:
- display outgoing connections even if the process name/path is unknown.
(src ip, dst ip, dst port, uid)
- get outgoing connection uid if kernel > 3.6.
