I think it was based on some set of (possibly now outmoded) DoD policy. And so the relationship to threat may not be clear. The DISA folks are most likely to know where it came from. Perhaps they could chime in.Since it was originally written a while ago, prior to the transition to SRGs based on security controls in NIST 800-53, it's likely worth revisiting. If the OS SRG contains all the auditing rules necessary for a STIG, and there are no additional DoD requirements, then we should certainly be able to consider adjustment.This has the OS SRG reqs:On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb <sgrubb@redhat.com> wrote:
_______________________________________________On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:And these rules are incomplete. You also need -S fchmod -S fchmodat -S
> 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
setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S
fremovexattr
This is not the output generated by the rule above. :-) To get that you would
> And here is the output of a normal workstation over about a week of
> auditing and normal usage:
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
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide