Suppress messages from /var/log/audit.log via audit.rules

[Steve Grubb]

On Thursday, September 29, 2011 11:51:00 AM Worsham, Michael wrote:
> The messages being detected are from a VMware Tools install on a RHEL 5.x
> platform, directly from the VMware Tools zip file. From what I can see
> upon a bit of research, it seems that VMware Tools is looking for files
> that don't exist nor are installed from the original zip package. Also, in
> the past I tried the following rules as well to no effect:
> 
> -a exit,never -F arch=b32 -S fork -F success=0 -F
> path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-ENOENT -a
> exit,never -F arch=b64 -S fork -F success=0 -F path=/usr/lib/vmware-tools
> -F subj_type=initrc_t -F exit=-ENOENT
> 
> This is the current rule set in its entirety:
> 
> # This file contains the auditctl rules that are loaded
> # whenever the audit daemon is started via the initscripts.
> # The rules are simply the parameters that would be passed
> # to auditctl.
> 
> # First rule - delete all
> -D
> 
> # Increase the buffers to survive stress events.
> # Make this bigger for busy systems
> -b 15000
> 
> # Feel free to add below this line. See auditctl man page
> 
> # Exclude all cwd message types
> -a exclude,always -F msgtype=CWD

You probably don't mean to suppress this., You may need it to reconstruct relative 
paths.


> ## Suppress all VMware Tools messages
> -a exit,never -F arch=b32 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F 
subj_type=initrc_t -F exit=-2 
> -a exit,never -F arch=b64 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F
> subj_type=initrc_t -F exit=-2 

Is ENOENT a valid return code for fork? I can't see what this rule is supposed to do. 
My guess is you at one time did not have 32 and 64 bit rules and were getting caught 
by open and fork sharing the same syscall number on 64/32 API's. I would delete this 
rule.


> #-a exit,never -F arch=b32 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F 
subj_type=initrc_t -F exit=4294967294 
> #-a exit,never -F arch=b64 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F 
subj_type=initrc_t -F exit=4294967294
> 
> #GEN002720
> -a always,exit -F arch=b32 -S open -F success=0
> -a always,exit -F arch=b64 -S open -F success=0

This is the rule that is killing you. Why do you want failures for ENOENT? Or EEXIST, 
EINTR, or many other meaningless errors? I would fix this rule to get failures that 
return EPERM or EACCES. Those are the security relevant failures.


> #GEN002740
> -a always,exit -F arch=b32 -S unlink -S rmdir
> -a always,exit -F arch=b64 -S unlink -S rmdir

This is also an overly aggressive rule that will get you all kinds of events that mean 
nothing. I would rewrite this. You might look at:

https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules

To get some ideas about how to fine tune the rules you are using. For one, nothing is 
using keys. You really want to add keys to all you rules so that you can see what 
kinds of things are happening on you system like:

aureport --start today --key --summary


> #GEN002760
> -w /etc/auditd.conf
> -w /etc/audit.rules
> -w /etc/audit/auditd.conf
> -w /etc/audit/audit.rules
> 
> -a always,exit -F arch=b32 -S stime -S acct -S reboot -S swapon -S
> settimeofday -S setrlimit -S setdomainname -S sched_setparam -S
> sched_setscheduler 
> -a always,exit -F arch=b64 -S acct -S reboot -S swapon -S settimeofday -S setrlimit 
-S setdomainname -S sched_setparam -S  sched_setscheduler
> 
> #GEN002820
> -a always,exit -F arch=b32 -S chmod -S fchmod -S chown -S chown32 -S fchown
> -S fchown32 -S lchown -S lchown32 
> -a always,exit -F arch=b64 -S chmod -S fchmod -S chown -S fchown -S lchown

Again way too aggressive rules and no keys to help analysis. I wrote an audit.rules 
man page that describes some of the consideration you might want to make in writing 
rules to conduct an investigation later.

-Steve