fapolicyd is a userspace daemon that determines access rights to files based on a trust database and file or process attributes. It can be used to either blacklist or whitelist file access and execution.
Configuring fapolicyd is done with the files in the /etc/fapolicyd/ directory. There are three files: fapolicyd.rules , fapolicyd.conf , and fapolicyd.trust
. The first one sets the access rights, the second determines the daemon's configuration, and the last allows admin defined trusted files.
The default rules will generate audit events whenever there is a denial. NOTE: you must have at least 1 audit rule loaded for the audit system to create the full FANOTIFY event. It doesn't matter which rule is loaded. To see if you have any denials, you can run the following command:
ausearch --start today -m fanotify -i
or instead of -i, you can add --format text to get an easier to read audit event.
leave the daemon in the foreground for debugging. Event information is written to stderr so that policy decisions can be observed.
leave the daemon in the foreground for debugging. Event information is written to stderr only when the decision is to deny access.
the daemon will allow file access regardless of the policy decision. This is useful for debugging rules before making them permanent.
when fapolicyd ends, it dumps a usage report with various statistics that may be useful for tuning performance. It can also detail which processes it knew about and files being accessed by them. This can be useful for forensics investigations. In some settings, this may not be desirable as the file names may be sensitive. Using this option removes process and file names leaving only the statistics. The default without giving this option is to generate a full report.
caused fapolicyd to discontinue processing events and exit.
Whatever you do, DO NOT TRY TO ATTACH WITH PTRACE. Ptrace attachment sends a SIGSTOP which cannot be blocked. Since your whole system depends on fapolicyd approving access to glibc and various critical libraries, that will not happen until SIGCONT is sent. The system can deadlock if the continue signal is not sent.
To get audit events, you must have auditing enabled and at least one systemcall rule loaded. Otherwise you will not get any events.
If the rpmdb is set as a trust source, you should minimize the number of 32 bit packages on the system. In such cases, there may be a 32 bit and 64 file with the same pathname. Obviously only one can exist on the disk. So, this will always cause database miscompares and cause a delay in the daemon being operational.
If you are running in the debug mode and wish to compare rule numbers reported in the output with which rule is actually triggering, you can see the rules with the corresponding number by running the following command:
/etc/fapolicyd/fapolicyd.conf - daemon configuration
/etc/fapolicyd/fapolicyd.rules - access control rules
/etc/fapolicyd/fapolicyd.trust - admin defined trusted files
/var/log/fapolicyd-access.log - information about what was being accessed.
fapolicyd-cli(1), fapolicyd.rules(5), fapolicyd.trust(5), and fapolicyd.conf(5)
fapolicyd-cli(1), fapolicyd.conf(5), fapolicyd.rules(5), fapolicyd.trust(5), rpm-plugin-fapolicyd(8).