Record Events that Modify User/Group Information - /etc/group
Installs auditd watches keyed audit_rules_usergroup_modification on the account databases (/etc/group, /etc/passwd, /etc/shadow, /etc/gshadow, /etc/security/opasswd) so every change is recorded.
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
Beyond auditing the creation of users and groups, these watches alert administrators to any modification of the account databases. Any unexpected user, group, or change to /etc/passwd, /etc/shadow or /etc/group should be investigated for legitimacy. Without these rules, an attacker who adds a backdoor account or escalates a UID to 0 leaves no trace in the audit trail, defeating forensic reconstruction of a compromise.
What Pavois checks
Pavois runs auditctl -l and checks the loaded, live kernel ruleset for a rule keyed audit_rules_usergroup_modification. Reading the live ruleset is decisive: a rule can sit in /etc/audit/rules.d/*.rules yet never be loaded (syntax error, augenrules not run, service not reloaded). Only auditctl -l proves the kernel is actually watching the files right now.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)audit_rules_usergroup_modification\b/) }
end
describe command("grep -rhwsE 'audit_rules_usergroup_modification' /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 audit_rules_usergroup_modification. Expect one -w watch per account file, e.g. -w /etc/group -p wa -k audit_rules_usergroup_modification. Then edit a file (e.g. chage a user) and confirm an event lands in the log.
Inspect & investigate
Generated events are written to /var/log/audit/audit.log. Because ausearch can wrongly report "no matches", grep the raw log: grep 'key="audit_rules_usergroup_modification"' /var/log/audit/audit.log. Service health: systemctl status auditd.
Remediation
pavois harden apply uses the audit_ruleset resource to drop a Pavois-managed rules file under /etc/audit/rules.d/ containing the -w ... -k audit_rules_usergroup_modification watches, then reloads auditd so the rules are loaded into the kernel. Because the audit ruleset is locked immutable (-e 2) on a hardened host, a reboot is flagged so the new rules take effect cleanly.
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
Operationally benign: these are passive -w watches with negligible overhead. Precautions: auditd watches consume the audit backlog, so pair this with an adequate audit_backlog_limit; on a host with the ruleset already locked (-e 2) the change only takes effect after reboot. If auditd's disk policy is halt/single and the partition fills, the machine can stop accepting actions, monitor /var/log/audit free space before locking the ruleset down.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | high |
| CIS | 10.2.1.5, 6.2.3.8, 6.3.3.8, 6.3.3.12, 6.3.3.14, 6.3.3.16, 6.3.3.15, 6.3.3.17, 6.3.3.13 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.7, AC-2(4), AC-6(9), 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.5 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-654130, UBTU-22-654135, UBTU-22-654140, UBTU-22-654145, UBTU-22-654150, UBTU-24-200290, UBTU-24-200310, UBTU-24-200320, UBTU-24-200280, UBTU-24-200300 | 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.