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

Tue Oct 4 02:36:31 UTC 2011

About the rule that’s 'killing' us (which I totally agree it is), this is what the stig.rules project says about it (GEN002720):

78    ## (GEN002720-GEN002840: CAT II) (Previously G100-G106) The SA will
79    ## configure the auditing system to audit the following events for all
80    ## users and root:
81    ##
82    ## - Logon (unsuccessful and successful) and logout (successful)
83    ##
84    ## Handled by pam, sshd, login, and gdm

But here is what the latest version of the Unix checklist says the vulnerability is, and how to check if its mitigated:

Unix Checklist v5r1-30 20110729
3.2.1.119
PDI:  GEN002720   – Audit Failed File and Program Access Attempts
PDI Description: The audit system is not configured to audit failed attempts to access files and programs.
Reference: UNIX STIG: 3.16
-  Linux

   For LAUS:
   # grep “@open-ops” /etc/audit/filter.conf

   For auditd:
   # grep “-a exit,always –S open –F success=0” /etc/audit.rules

The two don’t seem to jibe as to what the vulnerability is. I’m not sure how login, sshd, etc, can give information about failed attempts to access files.

As to altering the rule, while I’m sure the results would be much more useful and relevant (you can tell DISA’s thinking is out-of-date by the mitigation steps above), my only concern is that it would no longer be STIG compliant, or something that would always come up as a finding, that we would have to explain each time.

-- Michael

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

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

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.