Unfortunately, I completely understand the threat.
I believe the threat to be: If we know when all of these happen, then we'll
be able to figure out who is trying to do what in case something bad
happens.
I completely get it, but that's a heck of a lot of garbage data 99% of the
time. I guess the real question is: Is the garbage data worth the 1%?
In response to Steve:
Wouldn't it be interesting to see a permission change in a user's home
directory to 777 followed by some 644's or more 755's? This happens far too
often to get around pesky noexec settings on /tmp ;-).
Thanks,
Trevor
On Mon, Jul 1, 2013 at 9:04 PM, Jeffrey Blank <blank(a)eclipse.ncsc.mil>wrote:
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
>
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan(a)onyxpoint.com
-- This account not approved for unencrypted proprietary information --