2

I have a problem generating auditd rules on CentOS 7.

I have 2 .rules files in my /etc/audit/rules.d/ directory. Both files are owned by root and only root has access. When I reload the rules using augenrules --load then run auditctl -l it says No rules. Yet if I look at the contents of /etc/audit/audit.rules it does say it has been automatically generated from the .rules files and it does contain all of my rules from both files.

If I move either one of my .rules files out of that directory and reload the rules it works fine. The problem only seems to be when I have both files in there. I thought the point of the rules.d directory was that you could have multiple rule sets? Any ideas what I'm missing?

fitzplb
  • 21
  • 1
  • 1
  • 2
  • Found a typo in one of my `.rules` files. Now it works. Wonder why it was only a problem when the files were combined... – fitzplb Jun 16 '17 at 09:29
  • Can you share the .rules files so we might comment ... also identify the correction you made. – BurnA Jun 25 '17 at 07:51
  • 1
    @BurnA Can't share the whole file but I had a space in one of my "keyname" items like this: `-w /etc/docker/daemon.json -p wa -k docker CIS-1.11`. I changed it to: `-w /etc/docker/daemon.json -p wa -k docker-CIS-1.11` – fitzplb Jun 26 '17 at 08:42
  • OMG. I had the same problem. It's a little bit strange that `auditd` service is run successfully while the rules file has problems. Thanks anyway ;) – therealak12 Oct 31 '21 at 13:07

2 Answers2

2

Ok. For completeness, I believe the problem was that since the resultant /etc/audit/audit.rules had an error in it, when auditd attempted to restart, it got an error, and if one of the first directives was to delete all previous rules, then you ended up with no rules in place. IE

[root@stroomfp0 audit]# cat /etc/audit/audit.rules
## This file is automatically generated from /etc/audit/rules.d
-w /etc/docker/daemon.json -p wa -k docker CIS-1.11

[root@stroomfp0 audit]# 
[root@stroomfp0 audit]# service auditd restart
Stopping logging:                                          [  OK  ]
Redirecting start to /bin/systemctl start auditd.service
[root@stroomfp0 audit]# tail /var/log/messages
Jun 27 21:16:17 stroomfp0 systemd: Starting Security Auditing Service...
Jun 27 21:16:18 stroomfp0 auditd[10342]: Started dispatcher: /sbin/audispd pid: 10346
Jun 27 21:16:18 stroomfp0 audispd: No plugins found, exiting
Jun 27 21:16:18 stroomfp0 kernel: type=1305 audit(1498562178.008:701): 
audit_enabled=1 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1
Jun 27 21:16:18 stroomfp0 kernel: type=1305 audit(1498562178.010:702): audit_pid=10342 old=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1
Jun 27 21:16:18 stroomfp0 augenrules: /sbin/augenrules: No change
Jun 27 21:16:18 stroomfp0 auditctl: parameter passed without an option given
Jun 27 21:16:18 stroomfp0 auditctl: There was an error in line 5 of /etc/audit/audit.rules
Jun 27 21:16:18 stroomfp0 auditd[10342]: Init complete, auditd 2.6.5 listening for events (startup state enable)
Jun 27 21:16:18 stroomfp0 systemd: Started Security Auditing Service.
[root@stroomfp0 audit]# 

Once you corrected the error, regenerated the rules files and the resultant auditd restart demonstrated it all worked.

Moral of the story, always check the message log on weird activity :-)

BurnA
  • 401
  • 3
  • 6
  • 1
    Yes. That is how it works. I usually check the return code from augenrules to see if it was successful. If you have multiple files and you have a duplicate entry, the rules will not load. If you have a typo, the rules will not load. If you have a "path=" to a non-existent file, the rules will not load. There is a configuration item that says "keep loading even if errors are encountered", but this is not the default. You can use it with augenrules, but I do not know if you can configure this behavior when the audit daemon starts up. – Scottie H Jun 08 '21 at 16:19
0

It could be useful for someone troubleshooting.

You can run auditctl -R which will run rules based off a file and return errors if there is anything wrong with it.

auditctl -R /etc/audit/audit.rules
GwenM
  • 101
  • 1