Record Events that Modify User/Group Information via open syscall - /etc/group
Ensures auditd has an active rule tagged user-modify that records any access to account databases such as /etc/group, /etc/passwd and /etc/shadow.
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.
Why this rule matters
Creating or altering groups by editing /etc/group directly (instead of groupadd/gpasswd) can be a sign of malicious activity. Without an audit record of these writes, an attacker who adds themselves to a privileged group such as sudo or wheel leaves no trail, and incident responders cannot prove when or by whom the account database was tampered with.
What Pavois checks
Pavois runs auditctl -l and checks that a loaded rule carries the user-modify key. Reading the live kernel ruleset beats parsing /etc/audit/rules.d/*.rules: a rule present in a file but never loaded (syntax error, augenrules not run, service not restarted) gives a false sense of coverage. auditctl -l shows only what the kernel actually enforces right now.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)user\-modify\b/) }
end
describe command("grep -rhwsE 'user\-modify' /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 user-modify. You should see watch rules such as -w /etc/group -p wa -k user-modify (and matching lines for /etc/passwd, /etc/shadow, /etc/gshadow). Empty output means the rule is not loaded.
Inspect & investigate
Triggered events land in /var/log/audit/audit.log. Search with grep 'key="user-modify"' /var/log/audit/audit.log (note: ausearch -k user-modify can wrongly report no matches, so grep the raw log).
Remediation
Pavois's harden plan uses the audit_ruleset resource to write the watch rules into /etc/audit/rules.d/, then reloads auditd so the kernel picks them up. Because the audit config may be made immutable, a reboot is required for the change to fully take effect. Apply it with pavois harden apply.
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
Without this rule, edits to the account databases go unrecorded, blinding you to privilege-escalation and persistence attacks. The rule itself is purely observational and cannot break logins. Precautions: account-database files change on every legitimate user/group operation, so expect volume, size audit.log rotation and space_left_action so a full disk does not halt the system (when auditd is configured to halt).