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

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

[Worsham, Michael]

[-- Attachment #1.1: Type: text/plain, Size: 3928 bytes --]

Does anyone have an idea on how to suppress (exclude) these entries from showing up in the audit.log on a RHEL platform? I have tried the following to no success:


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)

type=CWD msg=audit(1316431049.130:131982949):  cwd="/"

type=PATH msg=audit(1316431049.130:131982949): item=0 name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/libc.so.6"

type=SYSCALL msg=audit(1316431049.130:131982950): 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)

type=CWD msg=audit(1316431049.130:131982950):  cwd="/"

type=PATH msg=audit(1316431049.130:131982950): item=0 name="/usr/lib/vmware-tools/lib64/libdnet.so.1/x86_64/libc.so.6"

type=SYSCALL msg=audit(1316431049.130:131982951): 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)

Packages installed:
redhat-release-5Server-5.7.0.3
audit-1.7.18-2.el5
selinux-policy-targeted-2.4.6-316.el5

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


________________________________
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.

[-- Attachment #1.2: Type: text/html, Size: 7082 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Vipin Rathor]

>From the little knowledge that I have -
For excluding 'cwd' type messages, try this at the beginning of rule file:
-a exclude,always -F msgtype=CWD

For other messages, try 'exit=4294967294' in rules. Not sure if this
will solve it, but worth a try.

On Thu, Sep 29, 2011 at 8:01 PM, Worsham, Michael <mworsham@scires.com> wrote:
> Does anyone have an idea on how to suppress (exclude) these entries from
> showing up in the audit.log on a RHEL platform? I have tried the following
> to no success:
>
>
>
> 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)
>
> type=CWD msg=audit(1316431049.130:131982949):  cwd="/"
>
> type=PATH msg=audit(1316431049.130:131982949): item=0
> name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/libc.so.6"
>
> type=SYSCALL msg=audit(1316431049.130:131982950): 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)
>
> type=CWD msg=audit(1316431049.130:131982950):  cwd="/"
>
> type=PATH msg=audit(1316431049.130:131982950): item=0
> name="/usr/lib/vmware-tools/lib64/libdnet.so.1/x86_64/libc.so.6"
>
> type=SYSCALL msg=audit(1316431049.130:131982951): 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)
>
>
>
> Packages installed:
>
> redhat-release-5Server-5.7.0.3
> audit-1.7.18-2.el5
> selinux-policy-targeted-2.4.6-316.el5
>
>
>
> 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
>
>
>
> ________________________________
> 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.
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>



-- 
-Rathor

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

[Worsham, Michael]

Well the CWD messages disappeared, but the remaining messages are still appearing:

type=PATH msg=audit(1317309325.053:226843501): item=0 name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/x86_64/libc.so.6"
type=SYSCALL msg=audit(1317309325.053:226843502): arch=c000003e syscall=2 success=no exit=-2 a0=7fff4be653d0 a1=0 a2=2b4aab9ca000 a3=6462696c2f343662 items=1 ppid=14038 pid=14040 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)
type=PATH msg=audit(1317309325.053:226843502): item=0 name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/libc.so.6"
type=SYSCALL msg=audit(1317309325.053:226843503): arch=c000003e syscall=2 success=no exit=-2 a0=7fff4be653d0 a1=0 a2=2b4aab9ca000 a3=6462696c2f343662 items=1 ppid=14038 pid=14040 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)
type=PATH msg=audit(1317309325.053:226843503): item=0 name="/usr/lib/vmware-tools/lib64/libdnet.so.1/x86_64/libc.so.6"
type=SYSCALL msg=audit(1317309325.053:226843504): arch=c000003e syscall=2 success=no exit=-2 a0=7fff4be653d0 a1=0 a2=2b4aab9ca000 a3=6462696c2f343662 items=1 ppid=14038 pid=14040 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)

Current rules:

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

-- Michael

________________________________________
From: Vipin Rathor [v.rathor@gmail.com]
Sent: Thursday, September 29, 2011 10:54 AM
To: Worsham, Michael
Cc: linux-audit@redhat.com
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules

>From the little knowledge that I have -
For excluding 'cwd' type messages, try this at the beginning of rule file:
-a exclude,always -F msgtype=CWD

For other messages, try 'exit=4294967294' in rules. Not sure if this
will solve it, but worth a try.

On Thu, Sep 29, 2011 at 8:01 PM, Worsham, Michael <mworsham@scires.com> wrote:
> Does anyone have an idea on how to suppress (exclude) these entries from
> showing up in the audit.log on a RHEL platform? I have tried the following
> to no success:
>
>
>
> 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)
>
> type=CWD msg=audit(1316431049.130:131982949):  cwd="/"
>
> type=PATH msg=audit(1316431049.130:131982949): item=0
> name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/libc.so.6"
>
> type=SYSCALL msg=audit(1316431049.130:131982950): 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)
>
> type=CWD msg=audit(1316431049.130:131982950):  cwd="/"
>
> type=PATH msg=audit(1316431049.130:131982950): item=0
> name="/usr/lib/vmware-tools/lib64/libdnet.so.1/x86_64/libc.so.6"
>
> type=SYSCALL msg=audit(1316431049.130:131982951): 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)
>
>
>
> Packages installed:
>
> redhat-release-5Server-5.7.0.3
> audit-1.7.18-2.el5
> selinux-policy-targeted-2.4.6-316.el5
>
>
>
> 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
>
>
>
> ________________________________
> 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.
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>



--
-Rathor

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 a
 ll applicable ITAR, EAR and embargo compliance requirements.

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

[Steve Grubb]

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

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

[Worsham, Michael]

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@redhat.com]
Sent: Thursday, September 29, 2011 11:41 AM
To: linux-audit@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 a
 ll applicable ITAR, EAR and embargo compliance requirements.

Re: 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

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

[Worsham, Michael]

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@redhat.com]
Sent: Thursday, September 29, 2011 9:51 PM
To: Worsham, Michael
Cc: linux-audit@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.

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

[Steve Grubb]

On Monday, October 03, 2011 10:36:31 PM Worsham, Michael wrote:
> 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

I'll have to double check the numbering. Things may have shifted since I wrote the 
stig.rules file.


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

This would appear that you are using an old stig.rules file. You might want to update 
it.
 
 
> 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.

The rules file is listing several requirements which has the rules in-between the 
requirements. The first part is to satisfy the logon/off requirements. Farther down is 
the unsuccessful access requirement.

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

I occassionally chat with the DISA FSO people. The intent is the stig.rules file in the 
audit package is compliant. I think they have altered the auditing requirements to 
match what is shipped. But you just need to update to a newer version of the file.

-Steve

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

[Worsham, Michael]

SRR still shows this as a failure, using stig.rules contents for audit.rules:

GEN002720: UNIX STIG: 3.16 - The audit system is not configured to audit failed attempts to access files and programs.
AUDITING is NOT correctly CONFIGURED on va33-time.
Ensure that -a exit,always -S open -F success=0 is in /etc/audit/audit.rules on va33-time.
PDI Number: GEN002720
Finding Category: CAT II
Reference: UNIX STIG: 3.16
Description: The audit system is not configured to audit failed attempts to access files and programs.
Status: Open


Is there any documentation that says that the stig.rules file is compliant for GEN002720? The project security folks will only be looking at the SRR output, which says it's not.

We are using the rules as found here: https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules

-- Michael


-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, October 04, 2011 9:18 AM
To: Worsham, Michael
Cc: linux-audit@redhat.com
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules

On Monday, October 03, 2011 10:36:31 PM Worsham, Michael wrote:
> 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

I'll have to double check the numbering. Things may have shifted since I wrote the
stig.rules file.


>    For LAUS:
>    # grep "@open-ops" /etc/audit/filter.conf
>
>    For auditd:
>    # grep "-a exit,always -S open -F success=0" /etc/audit.rules

This would appear that you are using an old stig.rules file. You might want to update
it.


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

The rules file is listing several requirements which has the rules in-between the
requirements. The first part is to satisfy the logon/off requirements. Farther down is
the unsuccessful access requirement.

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

I occassionally chat with the DISA FSO people. The intent is the stig.rules file in the
audit package is compliant. I think they have altered the auditing requirements to
match what is shipped. But you just need to update to a newer version of the file.

-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 a
 ll applicable ITAR, EAR and embargo compliance requirements.

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

[Steve Grubb]

On Tuesday, November 01, 2011 11:45:51 AM Worsham, Michael wrote:
> SRR still shows this as a failure, using stig.rules contents for
> audit.rules:
> 
> GEN002720: UNIX STIG: 3.16 - The audit system is not configured to audit
> failed attempts to access files and programs. AUDITING is NOT correctly
> CONFIGURED on va33-time.
> Ensure that -a exit,always -S open -F success=0 is in /etc/audit/audit.rules 

This ^^^ is wrong. For example, it does not limit the syscall by the arch. So what 
this means is that it will look up the open syscall for the arch that auditctl is. So, 
lets see what that does:

# ausyscall open
open               2

OK, now what does the 32 bit API think of it?
# ausyscall 2 i386
fork

So, that rule will watch for all 32 bit forks and 64 bit opens. Is that what your 
security folks want? 

Additionally, the intent of the STIG is to catch failed opens due to permission 
problems. You are going to trap normal system activity when glibc goes looking around 
for library resolution information. This will waste space in your logs and make it 
hard to find actual problems.


> PDI Number: GEN002720
> Finding Category: CAT II
> Reference: UNIX STIG: 3.16
> Description: The audit system is not configured to audit failed attempts to
> access files and programs. Status: Open
> 
> 
> Is there any documentation that says that the stig.rules file is compliant
> for GEN002720? 

There are no docs that I know of. I could write one, but would that be authoritative? 
:)

> The project security folks will only be looking at the SRR
> output, which says it's not.

And the SRR is completely wrong. So, they need to have some understanding that you 
either want a system configured right but failing the SRR's or matching the SRR's but 
configured wrong. I'd hate to be in your position, but that's where you are.
 
> We are using the rules as found here:
> https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules

These rules are correct. You can contact DISA to verify.

-Steve

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

[Worsham, Michael]

After contacting DISA today, here is what they responded with:

"The SRR script currently does not support RHEL 5, only 3 and 4. Also, the STIG for RHEL 5 is currently in draft form and a manual review would need to be performed on the assets: http://iase.disa.mil/stigs/os/unix/red_hat.html"



So I took a look at the RHEL 5 draft and found this entry:

Group ID (Vulid):  V-814
Group Title:  Audit failed file and program access attempts
Rule ID:  SV-27291r1_rule
Severity: CAT II
Rule Version (STIG-ID):  GEN002720
Rule Title: The audit system must be configured to audit failed attempts to access files and programs.

Vulnerability Discussion:  If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.

Responsibility:  System Administrator
IAControls:  ECAR-1, ECAR-2, ECAR-3

Check Content:
Check that auditd is configured to audit failed file access attempts.

# cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a always,exit" | grep -i "open"
If no results are returned, or the results do not contain "-S open" and "-F success=0", this is a finding.

Fix Text: Edit the audit.rules file and add the following line to enable auditing of failed attempts to access files and programs:
-a always,exit -F arch=<ARCH> -S open -F success=0 Restart the auditd service.


The 'Fix Text' sounds like it will still spam the audit.log or am I missing something?

-- Michael



-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Wednesday, November 02, 2011 1:12 PM
To: Worsham, Michael
Cc: linux-audit@redhat.com
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules

On Tuesday, November 01, 2011 11:45:51 AM Worsham, Michael wrote:
> SRR still shows this as a failure, using stig.rules contents for
> audit.rules:
>
> GEN002720: UNIX STIG: 3.16 - The audit system is not configured to audit
> failed attempts to access files and programs. AUDITING is NOT correctly
> CONFIGURED on va33-time.
> Ensure that -a exit,always -S open -F success=0 is in /etc/audit/audit.rules

This ^^^ is wrong. For example, it does not limit the syscall by the arch. So what
this means is that it will look up the open syscall for the arch that auditctl is. So,
lets see what that does:

# ausyscall open
open               2

OK, now what does the 32 bit API think of it?
# ausyscall 2 i386
fork

So, that rule will watch for all 32 bit forks and 64 bit opens. Is that what your
security folks want?

Additionally, the intent of the STIG is to catch failed opens due to permission
problems. You are going to trap normal system activity when glibc goes looking around
for library resolution information. This will waste space in your logs and make it
hard to find actual problems.


> PDI Number: GEN002720
> Finding Category: CAT II
> Reference: UNIX STIG: 3.16
> Description: The audit system is not configured to audit failed attempts to
> access files and programs. Status: Open
>
>
> Is there any documentation that says that the stig.rules file is compliant
> for GEN002720?

There are no docs that I know of. I could write one, but would that be authoritative?
:)

> The project security folks will only be looking at the SRR
> output, which says it's not.

And the SRR is completely wrong. So, they need to have some understanding that you
either want a system configured right but failing the SRR's or matching the SRR's but
configured wrong. I'd hate to be in your position, but that's where you are.

> We are using the rules as found here:
> https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules

These rules are correct. You can contact DISA to verify.

-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 a
 ll applicable ITAR, EAR and embargo compliance requirements.

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

[Steve Grubb]

On Thursday, November 03, 2011 01:06:52 PM Worsham, Michael wrote:
> After contacting DISA today, here is what they responded with:
> 
> "The SRR script currently does not support RHEL 5, only 3 and 4. Also, the
> STIG for RHEL 5 is currently in draft form and a manual review would need
> to be performed on the assets:
> http://iase.disa.mil/stigs/os/unix/red_hat.html"
 
Yes, its in draft which means there are no STIGs for RHEL5 or 6. However, I have met 
with them and there is an agreement that the stig file is correct until new 
requirements are levied.
 
 
> So I took a look at the RHEL 5 draft and found this entry:
> 
> Group ID (Vulid):  V-814
> Group Title:  Audit failed file and program access attempts
> Rule ID:  SV-27291r1_rule
> Severity: CAT II
> Rule Version (STIG-ID):  GEN002720
> Rule Title: The audit system must be configured to audit failed attempts to
> access files and programs.
> 
> Vulnerability Discussion:  If the system is not configured to audit certain
> activities and write them to an audit log, it is more difficult to detect
> and track system compromises and damages incurred during a system
> compromise.
> 
> Responsibility:  System Administrator
> IAControls:  ECAR-1, ECAR-2, ECAR-3
> 
> Check Content:
> Check that auditd is configured to audit failed file access attempts.
> 
> # cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a always,exit" |
> grep -i "open" If no results are returned, or the results do not contain
> "-S open" and "-F success=0", this is a finding.
> 
> Fix Text: Edit the audit.rules file and add the following line to enable
> auditing of failed attempts to access files and programs: 
> -a always,exit -F arch=<ARCH> -S open -F success=0
> Restart the auditd service.

Which is slightly better, but still wrong.


> The 'Fix Text' sounds like it will still spam the audit.log or am I missing
> something?

It would, which is a good reason its still a draft. This also doesn't cover the openat 
syscall which glibc uses. The NSA publishes a SNAC guide for RHEL5. You can find the 
latest at this location:

http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf

If you look in section 2.6.2.4.8, you will see the correct audit rule listed as CCE 
14917-9. This is what the RHEL5 STIG should map to in its XCCDF.

-Steve


> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, November 02, 2011 1:12 PM
> To: Worsham, Michael
> Cc: linux-audit@redhat.com
> Subject: Re: Suppress messages from /var/log/audit.log via audit.rules
> 
> On Tuesday, November 01, 2011 11:45:51 AM Worsham, Michael wrote:
> > SRR still shows this as a failure, using stig.rules contents for
> > audit.rules:
> > 
> > GEN002720: UNIX STIG: 3.16 - The audit system is not configured to audit
> > failed attempts to access files and programs. AUDITING is NOT correctly
> > CONFIGURED on va33-time.
> > Ensure that -a exit,always -S open -F success=0 is in
> > /etc/audit/audit.rules
> 
> This ^^^ is wrong. For example, it does not limit the syscall by the arch.
> So what this means is that it will look up the open syscall for the arch
> that auditctl is. So, lets see what that does:
> 
> # ausyscall open
> open               2
> 
> OK, now what does the 32 bit API think of it?
> # ausyscall 2 i386
> fork
> 
> So, that rule will watch for all 32 bit forks and 64 bit opens. Is that
> what your security folks want?
> 
> Additionally, the intent of the STIG is to catch failed opens due to
> permission problems. You are going to trap normal system activity when
> glibc goes looking around for library resolution information. This will
> waste space in your logs and make it hard to find actual problems.
> 
> > PDI Number: GEN002720
> > Finding Category: CAT II
> > Reference: UNIX STIG: 3.16
> > Description: The audit system is not configured to audit failed attempts
> > to access files and programs. Status: Open
> > 
> > 
> > Is there any documentation that says that the stig.rules file is
> > compliant for GEN002720?
> 
> There are no docs that I know of. I could write one, but would that be
> authoritative?
> 
> :)
> :
> > The project security folks will only be looking at the SRR
> > output, which says it's not.
> 
> And the SRR is completely wrong. So, they need to have some understanding
> that you either want a system configured right but failing the SRR's or
> matching the SRR's but configured wrong. I'd hate to be in your position,
> but that's where you are.
> 
> > We are using the rules as found here:
> > https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules
> 
> These rules are correct. You can contact DISA to verify.

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

[Worsham, Michael]

Thought you might like to know that I contacted DISA on this error and got a response:

Michael,

Thank you for bringing this issue to our attention it will be corrected in the final version of the STIG:

Action Description: GEN000460 :: INCORRECT AUDIT.RULES FINDING IN SRR SCRIPT FOR LINUX. ISSUE FOUND IN DRAFT RHEL 5 AS WELL, SEE ATTACHED EMAIL
AR Number: CSD-AR003085626
Assigned Group: CH-STIG-UNIX
Assigned Priority: 4
Assigned Technician: ADAMS, GARY
First Name: MICHAEL
Last Name: WORSHAM
Last Update User: ADAMSG
Organization: ND REGIONAL SUPPLY OFFICE COM/PRIVATE INDUSTRY
Element Id: FS-STIG : STIG Service 1: COMPUTING Service 2: FSO Service 3: UNIX Status or Resolution Summary: 11/7 - DEFER TO CORRECT IN RHEL5 STIG.
Status: DEFERRED
Zulu Date Time Out: 11/3/2011 18:05:53
Zulu Last Update Time: 11/7/2011 17:44:43

Gary Adams  CISSP, Security+
DISA FSO
HP Enterprise Services
COMM: 703-742-2929

-- Michael



-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Thursday, November 03, 2011 1:33 PM
To: Worsham, Michael
Cc: linux-audit@redhat.com
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules

On Thursday, November 03, 2011 01:06:52 PM Worsham, Michael wrote:
> After contacting DISA today, here is what they responded with:
>
> "The SRR script currently does not support RHEL 5, only 3 and 4. Also, the
> STIG for RHEL 5 is currently in draft form and a manual review would need
> to be performed on the assets:
> http://iase.disa.mil/stigs/os/unix/red_hat.html"

Yes, its in draft which means there are no STIGs for RHEL5 or 6. However, I have met
with them and there is an agreement that the stig file is correct until new
requirements are levied.


> So I took a look at the RHEL 5 draft and found this entry:
>
> Group ID (Vulid):  V-814
> Group Title:  Audit failed file and program access attempts
> Rule ID:  SV-27291r1_rule
> Severity: CAT II
> Rule Version (STIG-ID):  GEN002720
> Rule Title: The audit system must be configured to audit failed attempts to
> access files and programs.
>
> Vulnerability Discussion:  If the system is not configured to audit certain
> activities and write them to an audit log, it is more difficult to detect
> and track system compromises and damages incurred during a system
> compromise.
>
> Responsibility:  System Administrator
> IAControls:  ECAR-1, ECAR-2, ECAR-3
>
> Check Content:
> Check that auditd is configured to audit failed file access attempts.
>
> # cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a always,exit" |
> grep -i "open" If no results are returned, or the results do not contain
> "-S open" and "-F success=0", this is a finding.
>
> Fix Text: Edit the audit.rules file and add the following line to enable
> auditing of failed attempts to access files and programs:
> -a always,exit -F arch=<ARCH> -S open -F success=0
> Restart the auditd service.

Which is slightly better, but still wrong.


> The 'Fix Text' sounds like it will still spam the audit.log or am I missing
> something?

It would, which is a good reason its still a draft. This also doesn't cover the openat
syscall which glibc uses. The NSA publishes a SNAC guide for RHEL5. You can find the
latest at this location:

http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf

If you look in section 2.6.2.4.8, you will see the correct audit rule listed as CCE
14917-9. This is what the RHEL5 STIG should map to in its XCCDF.

-Steve


> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, November 02, 2011 1:12 PM
> To: Worsham, Michael
> Cc: linux-audit@redhat.com
> Subject: Re: Suppress messages from /var/log/audit.log via audit.rules
>
> On Tuesday, November 01, 2011 11:45:51 AM Worsham, Michael wrote:
> > SRR still shows this as a failure, using stig.rules contents for
> > audit.rules:
> >
> > GEN002720: UNIX STIG: 3.16 - The audit system is not configured to audit
> > failed attempts to access files and programs. AUDITING is NOT correctly
> > CONFIGURED on va33-time.
> > Ensure that -a exit,always -S open -F success=0 is in
> > /etc/audit/audit.rules
>
> This ^^^ is wrong. For example, it does not limit the syscall by the arch.
> So what this means is that it will look up the open syscall for the arch
> that auditctl is. So, lets see what that does:
>
> # ausyscall open
> open               2
>
> OK, now what does the 32 bit API think of it?
> # ausyscall 2 i386
> fork
>
> So, that rule will watch for all 32 bit forks and 64 bit opens. Is that
> what your security folks want?
>
> Additionally, the intent of the STIG is to catch failed opens due to
> permission problems. You are going to trap normal system activity when
> glibc goes looking around for library resolution information. This will
> waste space in your logs and make it hard to find actual problems.
>
> > PDI Number: GEN002720
> > Finding Category: CAT II
> > Reference: UNIX STIG: 3.16
> > Description: The audit system is not configured to audit failed attempts
> > to access files and programs. Status: Open
> >
> >
> > Is there any documentation that says that the stig.rules file is
> > compliant for GEN002720?
>
> There are no docs that I know of. I could write one, but would that be
> authoritative?
>
> :)
> :
> > The project security folks will only be looking at the SRR
> > output, which says it's not.
>
> And the SRR is completely wrong. So, they need to have some understanding
> that you either want a system configured right but failing the SRR's or
> matching the SRR's but configured wrong. I'd hate to be in your position,
> but that's where you are.
>
> > We are using the rules as found here:
> > https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules
>
> These rules are correct. You can contact DISA to verify.

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 a
 ll applicable ITAR, EAR and embargo compliance requirements.