Question about RHEL-06-000185

Steve Grubb sgrubb at redhat.com
Fri Jun 28 14:36:24 UTC 2013


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


More information about the scap-security-guide mailing list