This is actually pretty funny:
On a workstation:
685 /usr/bin/pidgin
377 /usr/lib64/firefox/firefox
186 /usr/libexec/gconfd-2
94 /usr/lib64/vte/gnome-pty-helper
60 /usr/bin/vim
56 /usr/bin/pulseaudio
49 /usr/bin/mesg
36 /bin/sed
30 /bin/vi
10 /usr/libexec/gdm-session-worker
8 /usr/libexec/gnome-settings-daemon
5 /usr/lib64/libreoffice/program/soffice.bin
4 /usr/bin/less
4 /usr/bin/ruby
4 /usr/bin/gnome-volume-control-applet
3 /usr/bin/evince
2 /usr/bin/vinagre
2 /usr/bin/gnome-panel
1 /sbin/rsyslogd
So, it looks like my biggest culprits are...PIdgin and Firefox
On a server:
Executable Summary Report
=================================
total file
=================================
63360 /usr/bin/ruby
202 /usr/bin/vim
55 /usr/sbin/sshd
36 /usr/bin/mesg
25 /bin/chmod
7 /usr/bin/python
5 /bin/chown
3 /usr/bin/less
2 /usr/sbin/httpd
2 /bin/vi
1 /usr/bin/man
1 /bin/chgrp
Tracking down the hits on Ruby was interesting.
It turns out that the auid > 500 works unless you run the command through a
sudo session. Then, your auid is > 500 but your euid is < 500 for a given
daemon service. Is this something that, from a guidance point of view, you
would recommend ignoring due to the sheer mass of garbage data, or should
it be collected since it's being run as a normal user?
Even so, 202 hits on VIM is a lot of garbage when you start aggregating
systems.
Thanks,
Trevor
On Thu, Jul 11, 2013 at 10:54 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Wednesday, July 10, 2013 11:36:47 PM Trevor Vaughan wrote:
> 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%?
Where are you seeing all these permission changes and what is doing it? You
gave a syscall report as evidence which is not helpful to understand what
the
issue is and how we might resolve it.
> 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 ;-).
If you wanted it, this will get it for you:
-a always,exit -S fchmodat -F dir=/home -F a2&0111 -F filetype=file -k
mkexe
-a always,exit -S fchmod,chmod -F dir=/home -F a1&0111 -F filetype=file -k
mkexe
But this will catch only a naive user. The truly crafty users have to be
caught another way. I'm still experimenting on how to do that.
-Steve
> 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/MA
> > C1PublicProfile/>
> > 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 --