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

Worsham, Michael mworsham at SCIRES.COM
Thu Sep 29 15:51:00 UTC 2011


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

## 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
#-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

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

#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


-- Michael

________________________________________
From: Steve Grubb [sgrubb at redhat.com]
Sent: Thursday, September 29, 2011 11:41 AM
To: linux-audit at redhat.com
Cc: Worsham, Michael
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules

On Thursday, September 29, 2011 10:31:06 AM Worsham, Michael wrote:
> type=CWD msg=audit(1316431049.130:131982948):  cwd="/"
>
> type=PATH msg=audit(1316431049.130:131982948): item=0
> name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/x86_64/libc.so.6"
>
> type=SYSCALL msg=audit(1316431049.130:131982949): arch=c000003e syscall=2
> success=no exit=-2 a0=7fffacb237a0 a1=0 a2=2abb06288000
> a3=6462696c2f343662 items=1 ppid=3921 pid=3923 auid=4294967295 uid=0 gid=0
> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
> comm="sed" exe="/bin/sed" subj=system_u:system_r:initrc_t:s0 key=(null)

This is an open syscall failing with ENOENT. You do not get audit events like this by
default. You have to have a rule that is triggering it. But which one? The results do
not have a key value attached to the rule, so you will need to look at your rules that
may catch failed opens. But this is really indicating a system problem. Why is a file
missing? Does it need the file? Is there some configuration option that is wrong?

Barring that, I would look at you rules that catch failed opens and ask if you really
meant to catch ENOENT? If not, I would rewrite those rules. The example rules shipped
with the audit package do not try to catch any failed open because glibc will look
around for certain files that normally do not exist and you get a lot of ENOENT
failures on any program startup. Instead, we only catch EPERM and EACCES failures
because those are the security relevant failures for open.


> Current rules:
> ## Suppress all VMware Tools system calls
>
> -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 -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

If you are intent on suppressing this rather than correcting the system setup or
existing rules, then just make sure these rules load before your other open based
syscall rules are loaded. Audit is first matching rule wins, so you want the
suppression to match before the one that generates the event.

-Steve

CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s).  This email may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.




More information about the Linux-audit mailing list