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 > [email protected] > https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
