Re: Excluding few executable from audit.rules in redhat6.5

[Steve Grubb <sgrubb@redhat.com>]

On Monday, November 17, 2014 03:02:12 PM Tilden Doran D wrote:
> I am new to Redhat Audit logging.
> Our Server Configurations:  Redhat 6.5 OS and Oracle 11g ,  and SELinux is
> enabled.
> 
> We are getting lots of logs messages  in /var/log/messages.
> 
> type=SYSCALL msg=audit(1416235337.083:2109222): arch=c000003e syscall=90
> success=yes exit=0 a0=7f52ae9f1a20 a1=3ff a2=ffffffffffffff88
> a3=fffffffffffffff0 items=1 ppid=1 pid=46859 auid=500 uid=345 gid=345
> euid=345 suid=345 fsuid=345 egid=345 sgid=345 fsgid=345 tty=(none) ses=28
> comm="ohasd.bin" exe="/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="perm_mod"
> type=PATH msg=audit(1416235337.083:2109222): item=0
> name="/opt/oracle_homes/oracle/grid/11.2.0/auth/ohasd/dl360x3364/A7679703"
> inode=4718596 dev=fd:00 mode=041755 ouid=345 ogid=345 rdev=00:00
> obj=unconfined_u:object_r:usr_t:s0 nametype=NORMAL
> 
> 
> Later we found and removed message type "CWD", but still we are  getting lot
> of logs.
> 
> And also found that the below mentioned executable are creating the problem.
> 
> 13351. 11/16/2014 18:11:34
> /opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin (none) ? 500 1599360
> 13352. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/rdbms/11.2.0/bin/oracle
> (none) ? 500 1599354 13353. 11/16/2014 18:11:34
> /opt/oracle_homes/oracle/grid/11.2.0/bin/oraagent.bin (none) ? 500 1599361
> 
> Can you  please help me in excluding the above mentioned Executable `s in
> the audit. rules files .

Well, what do you really want to do? In general, I'd look at the original 
auditing rule to see if its scope can be narrowed. In this case, it appears 
that you are wanting all calls to chmod. Why? Are you more concerned with 
failed calls to chmod, meaning a user is trying to change system files? Are 
system daemons calling chmod OK? Or do you really want everything? Or do you 
want no events at all for that daemon no matter what the syscall?

The event you are showing is that app successfully making a directory world 
writable/readable. Its setting the sticky bit, so its "safe."

-Steve