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"
}
It looks like it's part of python since 3.2, and as far as I can tell
without the pip dependency work just fine (tested on ubuntu >=14.x, mint
>= 18, debian >= 8.x).
It should also help packaging for ArchLinux #8.
It looks like it's part of python since 3.2, and as far as I can tell
without the pip dependency work just fine (tested on ubuntu >=14.x, mint
>= 18, debian >= 8.x).
Some people has asked where they can change the daemon configuration.
As we can't change it from the GUI yet, and we're providing deb
packages, we need to distribute a default config.
That way the users will see it and will be able to customize it.
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.
If we can't communicate with the server (UI), apply the default
configured action. For example, if the UI is doing too much work and it
reaches the timeout, or if there's a programming error (python exception
for instance).
Sometimes the INPUT rule for to queue DNS responses was not deleted.
The code has also been reorganized.
And a minor tweak to make an if{} more idiomatic.
