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

[Steve Grubb <sgrubb@redhat.com>]

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

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