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