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@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/MAC1PublicProfile/


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:
> 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@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




--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com

-- This account not approved for unencrypted proprietary information --