Question about RHEL-06-000185

Jeffrey Blank blank at eclipse.ncsc.mil
Tue Jul 2 01:04:58 UTC 2013


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 at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130701/6fae2fc9/attachment-0001.html>


More information about the scap-security-guide mailing list