Record Unsuccessful Access Attempts to Files - creat
Enforces an auditd rule (key access) that records unsuccessful (permission-denied) file access and modification attempts.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
Unsuccessful attempts to access or modify files, those failing with EACCES (permission denied) or EPERM (operation not permitted), are a strong indicator of malicious activity such as an attacker probing the filesystem or trying to escalate beyond their rights. Auditing these failed creat/open/openat/truncate calls captures evidence of attempted compromise that a successful-only audit policy would miss.
What Pavois checks
Pavois runs auditctl -l and checks a rule with the key access is loaded. Reading the live kernel ruleset beats parsing /etc/audit/rules.d/*.rules: a rule on disk that was never loaded (no augenrules --load, syntax error, reload failure) would make a file scanner falsely pass. auditctl -l reflects what the kernel audits now.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)access\b/) }
end
describe command("grep -rhwsE 'access' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run auditctl -l | grep -E '(-k |key=)access' (as root). Expected output is the syscall rules capturing EACCES/EPERM failures, for example:
-a always,exit -F arch=b64 -S creat,open,openat,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access-a always,exit -F arch=b64 -S creat,open,openat,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
No output means the rules are not loaded.
Inspect & investigate
Events go to /var/log/audit/audit.log. After a denied file access, find the record with grep 'key="access"' /var/log/audit/audit.log (grep the raw log; ausearch can falsely report no matches). The record shows the auid, the failing syscall, the target file and the EACCES/EPERM exit code.
Remediation
pavois harden apply uses the audit_ruleset resource to add the missing access syscall rules to a Pavois-managed drop-in in /etc/audit/rules.d/ and load them. Because the audit subsystem is locked once running, the change is fully effective only after a reboot (reboot_required: true).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
These are passive syscall watches, they only record failed accesses and never block anything, so applications keep working; they only add records to /var/log/audit/audit.log. Precautions:
- Permission-denied events are common in normal operation (applications probing optional paths), so this rule can be noisy, ensure
/var/log/audithas space and rotation and considerauditd's backlog limit before enabling on busy hosts. - If the ruleset is immutable (
-e 2), the rule can only be added after a reboot. - Confirm the rule parsed with
augenrules --loadand re-checkauditctl -l.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | high |
| CIS | 6.2.3.7, 6.3.3.11, 6.3.3.7 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.7, AU-12(c), AU-2(d), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.2.1.4 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-654165, UBTU-24-900160 | direct | per OS STIG release | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.