Hi,

Please find my response. Sorry for the delay, I am in different Time zone.

Well, what do you really want to do?

[Tilden] we want to implement audit Logging in Rhel 6.5. for the following events/actions.

Rebooting the system, adding and deleting users, changing auditing and logging parameters, changing system clock:(all administrative actions),

Process start and stop

User executes a command

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?

[Tilden] My Audit.rules file for your reference. If possible please suggest me to narrowed down the audit rules for my requirement.

## First rule - delete all

-D

## Increase the buffers to survive stress events.

## Make this bigger for busy systems

-b 8192

## Set failure mode to panic

-f 2

## Things that could affect time

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change

-a always,exit -F arch=b64 -S clock_settime -F a0=0 -k time-change

-w /etc/localtime -p wa -k time-change

## Things that affect identity

-w /etc/group -p wa -k identity

-w /etc/passwd -p wa -k identity

-w /etc/gshadow -p wa -k identity

-w /etc/shadow -p wa -k identity

-w /etc/security/opasswd -p wa -k identity

## Things that could affect system locale

-a always,exit -F arch=b64 -S sethostname -S setdomainname -k system-locale

-w /etc/issue -p wa -k system-locale

-w /etc/issue.net -p wa -k system-locale

-w /etc/hosts -p wa -k system-locale

-w /etc/sysconfig/network -p wa -k system-locale

## Things that could affect MAC policy

-w /etc/selinux/ -p wa -k MAC-policy

## - Logon (unsuccessful and successful) and logout (successful)

-w /var/log/tallylog -p wa -k logins

-w /var/run/faillock/ -p wa -k logins

-w /var/log/lastlog -p wa -k logins

##- Discretionary access control permission modification (unsuccessful

## and successful use of chown/chmod)

-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

##- Unauthorized access attempts to files (unsuccessful)

-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access

-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access

##- Use of privileged commands (unsuccessful and successful)

## use find /bin -type f -perm -04000 2>/dev/null and put all those files in a rule like this

-a always,exit -F path=/bin/ping -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged

##- Export to media (successful)

-a always,exit -F arch=b64 -S mount -F auid>=500 -F auid!=4294967295 -k export

## sudo cannot record the action.

-w /etc/sudoers -p wa -k actions

## Optional - could be an attempt to bypass audit or simply legacy program

-a always,exit -F arch=b64 -S personality -F a0!=4294967295 -k bypass

Are you more concerned with failed calls to chmod, meaning a user is trying to change system files?

[Tilden] Yes, I am more concern with User level auditing. i.e. what and all actions performed by the user should be logged. we don’t want the System process or any executable to generate logs.

Are system daemons calling chmod OK? Or do you really want everything?

[Tilden] We don’t want the System process / daemons logs

Or do you want no events at all for that daemon no matter what the syscall?

[Tilden] Yes, we found 3 daemons which is causing the issue of generating lot of logs message, so we want to restrict those daemons from generating log messages, as we want only User level audit logs.

Thanks

Tilden

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Monday, November 17, 2014 9:01 PM
To: linux-audit@redhat.com
Cc: Tilden Doran D
Subject: Re: Excluding few executable from audit.rules in redhat6.5

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