Question about RHEL-06-000185
Steve Grubb
sgrubb at redhat.com
Fri Jun 28 14:36:24 UTC 2013
On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:
> I've been running in compliance with this rule for quite some time now and
> I'm noticing that the amount of noise that it produces is simply outrageous.
>
> The suggestion is:
>
> At a minimum the audit system should collect file permission changes for
> all users and root. Add the following to "/etc/audit/audit.rules":
>
> -a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \
> -k perm_mod
>
> If the system is 64 bit then also add the following:
>
> -a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \
> -k perm_mod
And these rules are incomplete. You also need -S fchmod -S fchmodat -S
setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S
fremovexattr
> And here is the output of a normal workstation over about a week of
> auditing and normal usage:
This is not the output generated by the rule above. :-) To get that you would
to run:
ausearch --start this-week -k perm_mod
What is more interesting than the syscall list you have below is the files and
programs causing it
ausearch --start this-week -k perm_mod --raw | aureport -x --summary
and
ausearch --start this-week -k perm_mod --raw | aureport -f --summary
Personally, I don't think its terribly interesting to see permission changes
in a user's home directory. You might want to know that permissions changed on
the user's home dir, but its uninteresting for anything it contains.
I can certainly see this as interesting for system directories. Anyone recall
what the threat was that this rule was watching for?
-Steve
> Syscall Summary Report
> ==========================
> total syscall
> ==========================
> 24907 chmod
> 15870 chown
> 11169 rename
> 7409 open
> 6462 fchmod
> 5290 fchown
> 3687 umount2
> 1443 setsid
> 1166 fsetxattr
> 869 removexattr
> 456 adjtimex
> 360 fchmodat
> 337 lchown
> 211 setuid
> 69 mkdir
> 63 setsockopt
> 33 unlink
> 22 setxattr
> 20 clone
> 19 execve
> 7 fchownat
> 7 mount
> 7 creat
> 4 close
> 4 ioctl
> 3 symlink
> 2 mknod
> 1 rmdir
> 1 lsetxattr
> 1 clock_settime
> 1 capset
>
> So, I get why this can be useful. But I'm not so sure that it's useful to
> know that Pidgin dropped a new temp file every few minutes or that, each
> time I open a file (and write a temp file), that I did this as a normal
> user.
>
> I just can't see the practicality of going through those top three calls on
> a regular basis.
>
> I'm not necessarily suggesting that this type of thing be dropped but I'd
> like to understand how auditors won't fall into just ignoring them
> completely.
>
> Thoughts?
>
> Thanks,
>
> Trevor
More information about the scap-security-guide
mailing list