Bug 2181539
| Summary: | No FANOTIFY event seen in audit log upon denial | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> |
| Component: | fapolicyd | Assignee: | Radovan Sroka <rsroka> |
| Status: | CLOSED MIGRATED | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.7 | CC: | dapospis, rbriggs, sgrubb |
| Target Milestone: | rc | Keywords: | MigratedToJIRA, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-08-16 14:57:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I think that by default design nothing is sent to audit when some type of debug is there. I need to check this deeper. Even in non-debug nothing shows. I tried also with booting with `audit=1` just in case. It there at least one audit rule in place? That's the usual issue with audit messages. One needs to have at least one rules to enable logging of anything. e.g echo -e "-D"$'\n'"-w /etc/shadow -p w" >> /etc/audit/rules.d/audit.rules systemctl restart auditd Good catch! No I don't have any. That's clearly something to "fix" in audit daemon then, because customers may struggle (and Support) and never find anything in sosreports. Because for AVCs, it's not the case, we get them all the time, even with no audit rule active. Customer may not, they actually do! I'm not sure what would be the proper solution. Anyway, a BZ to at least have a discussion won't hurt. Filed BZ #2182660 against audit, since it's not related to FANOTIFY, it's general issue. I lost several hours again today due to this. This is not an audit daemon problem. The issue is that there is an inline kernel function, audit_fanotify(), called by the fanotify subsystem when an audit event is to be recorded. In it, it calls check_dummy_context(). If there are no audit rules loaded, it returns without logging the event. Because this is another security subsystem, it probably should not be subjected to the dummy context check. (SE linux is not subjected to it.) The main question would be if that check were taken away, is there/will there be enough information on hand to record something meaningful at syscall exit? If not, then at the most fapolicyd could do a check to see if audit rules are loaded and warn if it knows decisions are to be logged to the audit system and there are no rules. I understand, not only fanotify is impacted but other subsystems as well (see other bz #2182660): 2246 void audit_log_path_denied(int type, const char *operation) 2247 { 2248 struct audit_buffer *ab; 2249 2250 if (!audit_enabled || audit_dummy_context()) 2251 return; : In most cases, the dummy context check is necessary due to balancing performance needs and simply being too late in the syscall to collect enough meaningful information. It would be a case by case basis to see if it can be removed. This discussion leads me to an ultimate question: is the audit log target good default, then? This should be re-targeted as a kernel/audit bug to get rid of the dummy_context check so that a rule is not needed. This bug is going to be migrated. Contact point for migration questions or issues: rsroka Guidance for Bugzilla users to test their Jira account or create one if needed: https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016394 https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016694 https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016774 |
Description of problem: Playing around with fapolicyd, installed on a freshly new system, with no specific post configuration performed, I noticed that denials weren't leading to FANOTIFY audit events, e.g. with `fapolicyd --debug-deny` executing: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- [user@vm-fapolicy8 ~]$ ./hello -bash: ./hello: Operation not permitted # journalctl --follow -u fapolicyd.service [...] Mar 24 14:18:06 vm-fapolicy8 fapolicyd[2049]: rule=13 dec=deny_audit perm=execute auid=1000 pid=2086 exe=/usr/bin/bash : path=/home/user/hello ftype=application/x-executable trust=0 # ausearch -m FANOTIFY -ts recent <no matches> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Version-Release number of selected component (if applicable): audit-3.0.7-4.el8.x86_64 fapolicyd-1.1.3-8.el8_7.1.x86_64 kernel-core-4.18.0-425.13.1.el8_7.x86_64 How reproducible: Always Steps to Reproduce: 1. Build a custom untrusted binary -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- [user@vm-fapolicy8 ~]$ cat > hello.c << EOF #include <stdio.h> int main(int argc, char *argv[]) { printf("Hello!\n"); return 0; } EOF [user@vm-fapolicy8 ~]$ gcc -o hello hello.c -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 2. Try executing it -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- [user@vm-fapolicy8 ~]$ ./hello -bash: ./hello: Operation not permitted -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 3. Check for audit event -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- [root@vm-fapolicy8 ~]# ausearch -m FANOTIFY -ts recent <no matches> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Actual results: None Expected results: Some event