Excluding few executable from audit.rules in redhat6.5

[Tilden Doran D]

Hi 

auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A exit,never -F arch=b64 -S chmod -F uid=345

we  would  require a permanent fix.  If UID=345 is used, I believe that all auditing functionality will not work for user ID=345,  I mean if the userId(345) is logging in manually to the system and does some operation that will also be exclude.  We want User inventions  logs messages to be captured    but exclude the System generated logs. 

To be more detail. 

Ohasd.bin process is started by the user( while starting the database process) we want to captured this log.
But after that the ohasd.bin process is running in background and it does lot of read write operations, we don't want those logs. 

Can you please let us know the way forward. 


thanks
Tilden


-----Original Message-----
From: linux-audit-bounces at redhat.com [mailto:linux-audit-bounces at redhat.com] On Behalf Of Steve Grubb
Sent: Monday, November 17, 2014 10:39 PM
To: linux-audit at redhat.com
Subject: Re: Excluding few executable from audit.rules in redhat6.5

On Monday, November 17, 2014 11:42:17 AM Steve Grubb wrote:
> On Monday, November 17, 2014 10:14:59 AM LC Bruzenak wrote:
> > On 11/17/2014 09:30 AM, Steve Grubb wrote:
> > > 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."
> > 
> > I think this is auditing because the supplied STIG rules specify it.
> > The "perm_mod" key is the hint. You probably do not want to remove 
> > this rule for all chmod syscalls.
> 
> OK. Missed that. Then looking at the rule, it has an exclusion for 
> daemons because its only concerned with auid>=500. So, that means that 
> someone restarted the daemon by hand rather than rebooting the system
> 
> If a temporary fix is needed until the systems is rebooted, then one 
> could do this:
> 
> auditctl -A exit,never -S chmod -F uid=345

A correction is in order, this likely needs arch fields to be added. It should have been:

auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A exit,never -F arch=b64 -S chmod -F uid=345

-Steve

> That will get rid of all chmod calls by user account 345. Notice the 
> capital A, this places the rule at the beginning because the rule that 
> matches first wins. I would not make that a permanent rule, just a 
> workaround until it can be rebooted. But also note that it could 
> trigger other rules because it has a user's auid.
> 
> > You cannot exclude an executable itself from the rule set by name.
> > The "exclude" option only applies to event types.
> > 
> > You could exclude it by type, except it is running as a generic 
> > unconfined_t.
> 
> Yeah, as a daemon it should be something else. Unconfined is only from 
> a user session. Daemons get initrc_t when they are unknown.
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

--
Linux-audit mailing list
Linux-audit at redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit