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:
http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/M...
On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
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
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide