search

linux-application-whitelisting / fapolicyd

File Access Policy Daemon
GNU General Public License v3.0
192 stars 55 forks source link

Distinguish reasons for denial #263

Closed wjhunter3 closed 9 months ago

wjhunter3 commented 1 year ago

Unless I've missed something, there doesn't seem to be any indication for a denial because a file isn't trusted vice a file that has a hash mismatch. When parsing the audit/log notifications it would be helpful to distinguish between a new file that hasn't been trusted yet vice a file that violates the trust - either fapolicyd's trust db or the rpmdb - to flag possible shenanigans/malevolence.

stevegrubb commented 1 year ago

If you are on a recent kernel, the info you want should be available in the FANOTIFY record:

type=FANOTIFY msg=audit(08/12/2023 08:32:32.152:593) : resp=deny fan_type=rule_info fan_info=17 subj_trust=unknown obj_trust=no

This ^^^ says rule 17 is the reason it was denied, the subject was not evaluated, and the object was untrusted. Rule 17 is:

  1. deny_audit perm=execute all : all

which is the catch all.

wjhunter3 commented 1 year ago

Unfortunately our target platform is RHEL 8, so there's no "fan_*" information in the audit log.

stevegrubb commented 1 year ago

The extra information is in the process of being backported. (The patch landed in the upstream kernel around February.) Until then, the information can be ade available by choosing syslog as the logging target. Change deny_audit to deny_syslog. Then you can find all the information in syslog.

stevegrubb commented 9 months ago

I think this issue can be closed. Using syslog is the workaround until kernel patches are backported.