From: Richard Guy Briggs <[email protected]>
[ Upstream commit ce8370e2e62a903e18be7dd0e0be2eee079501e1 ]
When no audit rules are in place, fanotify event results are
unconditionally dropped due to an explicit check for the existence of
any audit rules. Given this is a report from another security
sub-system, allow it to be recorded regardless of the existence of any
audit rules.
To test, install and run the fapolicyd daemon with default config. Then
as an unprivileged user, create and run a very simple binary that should
be denied. Then check for an event with
ausearch -m FANOTIFY -ts recent
Link: https://issues.redhat.com/browse/RHEL-9065
Signed-off-by: Richard Guy Briggs <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
LLM Generated explanations, may be completely bogus:
## Backport Recommendation: **YES**
### Executive Summary
This commit fixes a significant security audit gap where fanotify access
control decisions are silently dropped when no audit rules are
configured. This is a critical bug for compliance and security
monitoring, especially for systems using fapolicyd or other fanotify-
based security tools.
---
## Detailed Analysis
### 1. Code Change Analysis
**File**: `include/linux/audit.h`
**Function**: `audit_fanotify()` (line 528-532)
**Change**:
```c
- if (!audit_dummy_context()) // Checks if audit rules are configured
+ if (audit_enabled) // Checks if audit subsystem is enabled
```
**What this means**:
- `audit_dummy_context()`: Returns `true` when there's no audit context
OR no audit rules configured
- `audit_enabled`: Global flag indicating if the audit subsystem is
enabled
**Effect**: fanotify events are now logged whenever audit is enabled,
regardless of whether specific audit rules exist.
### 2. Historical Context
**2017** (commit de8cd83e91bc3): fanotify audit logging introduced by
Steve Grubb with `!audit_dummy_context()` check
**2018** (commit 15564ff0a16e2): Similar check added to ANOM_LINK to
prevent "disjointed records when audit is disabled" (GitHub issue #21)
**2025** (commit ce8370e2e62a9): **This fix** - recognizes security
events should be logged regardless of rules
**2025** (commit 654d61b8e0e2f): Companion fix for AUDIT_ANOM_* events
with same rationale
### 3. The Bug's Impact
**Scenario**: System running fapolicyd (file access policy daemon) with:
- Audit subsystem enabled (`audit_enabled = 1`)
- No specific audit rules configured (`audit_dummy_context() = true`)
**Before this fix**:
- fanotify denies file execution
- User receives "permission denied" error
- **ZERO audit trail** of this security decision
- Compliance violation (Common Criteria, PCI-DSS, etc.)
- Security incident investigation impossible
**After this fix**:
- Same access control behavior
- **Audit record created**: `type=FANOTIFY msg=audit(...): resp=2
fan_type=1 ...`
- Proper security audit trail maintained
- Compliance requirements met
### 4. Why This Matters
**Security Subsystem Integration**: fanotify is a security subsystem
that explicitly requests auditing via the `FAN_AUDIT` flag (see
fs/notify/fanotify/fanotify.c:279-282). When a security subsystem says
"audit this decision," it should be honored.
**Compliance Requirements**: Organizations subject to:
- Common Criteria (explicitly mentioned in original 2017 commit
de8cd83e91bc3)
- PCI-DSS (requires audit trail of access control decisions)
- SOC 2, ISO 27001, HIPAA (all require security event logging)
Cannot afford missing security events in audit logs.
**Real-world Use Case**: The commit message provides a concrete test
case with fapolicyd:
```bash
# Install fapolicyd with default config
# As unprivileged user, create and run a denied binary
# Check for event:
ausearch -m FANOTIFY -ts recent
```
Without this fix, `ausearch` returns nothing despite the denial
occurring.
### 5. Risk Assessment
**Regression Risk**: **VERY LOW**
- One-line change in a header file
- Only affects logging behavior, not access control logic
- No changes to fanotify permission enforcement
- Pattern already proven in companion commit for ANOM_* events
(654d61b8e0e2f)
**Side Effects**:
- Slightly increased audit log volume (only when fanotify with FAN_AUDIT
is actively used)
- This is **intended behavior** - these events were always supposed to
be logged
**Testing**: Commit message includes specific test procedure using
fapolicyd
### 6. Stable Tree Suitability
**Meets stable kernel criteria**:
- ✅ Fixes important bug affecting users (missing security audit trail)
- ✅ Small, contained change (1 line in 1 file)
- ✅ No architectural changes
- ✅ Minimal regression risk
- ✅ Confined to audit subsystem
- ✅ Fixes unintended consequence of earlier commit
- ✅ Already auto-selected for backport (commit 5b2142179744e by Sasha
Levin)
**Evidence of importance**:
- Linked to RHEL-9065 (Red Hat identified this as significant)
- Part of a series addressing similar audit gaps (see commit
654d61b8e0e2f for ANOM_*)
- Affects compliance-critical functionality
### 7. Related Context
This fix is part of a broader pattern recognizing that **security events
should be logged differently than regular audit events**:
**Security events** (should log if `audit_enabled`):
- fanotify access control decisions (this commit)
- AUDIT_ANOM_LINK, AUDIT_ANOM_CREAT security violations (commit
654d61b8e0e2f)
- Other security subsystem reports
**Regular events** (need `!audit_dummy_context()`, i.e., require rules):
- Syscall auditing
- File access tracking
- Most other audit events
### 8. Code References
- Original fanotify audit introduction: de8cd83e91bc3 (2017)
- Problematic check added: 15564ff0a16e2 (2018)
- This fix: ce8370e2e62a9 (2025)
- Already backported as: 5b2142179744e
- Companion ANOM fix: 654d61b8e0e2f
- fanotify call site: fs/notify/fanotify/fanotify.c:282
- Function definition: include/linux/audit.h:528-532
---
## Recommendation
**STRONG YES** - This commit should be backported to stable kernel
trees.
**Justification**:
1. Fixes critical security audit gap with real-world impact (fapolicyd
users)
2. Minimal, surgical fix with very low regression risk
3. Already identified as important by Red Hat (RHEL-9065) and auto-
selected by stable maintainers
4. Essential for compliance requirements (Common Criteria, PCI-DSS,
etc.)
5. Part of a well-understood pattern of fixes for security event logging
6. No architectural changes, no API changes, no performance impact
7. Missing security audit trails are a serious compliance and incident
response issue
include/linux/audit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index a394614ccd0b8..e3f06eba9c6e6 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -527,7 +527,7 @@ static inline void audit_log_kern_module(const char *name)
static inline void audit_fanotify(u32 response, struct
fanotify_response_info_audit_rule *friar)
{
- if (!audit_dummy_context())
+ if (audit_enabled)
__audit_fanotify(response, friar);
}
--
2.51.0
