At the top of /etc/audit/audit.rules
on Centos7 it tells me:
## This file is automatically generated from /etc/audit/rules.d
Okay, so I went and looked, and found /etc/audit/rules.d/audit.rules
. It had the following line
# Feel free to add below this line. See auditctl man page
Which I did, and found what looked like maybe it was the option:
-R file
Read rules from a file. The rules must be 1 per line and in the order that they are to be executed in. The rule file must be
owned by root and not readable by other users or it will be rejected. The rule file may have comments embedded by starting
the line with a '#' character. Rules that are read from a file are identical to what you would type on a command line except
they are not preceded by auditctl (since auditctl is the one executing the file) and you would not use shell escaping since
auditctl is reading the file instead of bash.
But I ran auditctl -R /etc/audit/rules.d/audit.rules
which seemed to work, however it didn't do anything to /etc/audit/audit.rules
.
What's the right way to regenerate that file?
The utility augenrules builds /etc/audit/audit.rules from the *.rules files found in the directory /etc/audit/rules.d.
This utility is called from the auditd service (or you could call it by hand followed by loading the rules files as you discovered - but restarting the service is simpler).
I can't remember the reason why the auditd system cannot use systemd natively. Check the [email protected] mailing list archives.
Regeneration of rules in the file
/etc/audit/audit.rules
uses the rule files contained in/etc/audit/rules.d/
. That's the case for RHEL7/CentOS7 and, if memory serves, also for RHEL6/CentOS6.Do the following as root or with sudo:
sudo augenrules --check
If changes were detected, update with:
sudo augenrules --load
Any changes made to files in
/etc/audit/rules.d/
should now also show up in/etc/audit/audit.rules
.To make sure any change(s) are active, restart auditd:
sudo systemctl restart auditd
Check if the change is active / in use:
sudo auditctl -l | grep -i [your change value]
If the change is not found, auditd could be running in 'immutable' mode, meaning that you must reboot for any changes to become active since 'immutable' will not allow auditd changes on a running system, even as root. If running 'immutable', any auditd restart attempts will fail and 'systemctl' should alert you to that fact.