<div dir="ltr"><div><div><div><div><div><div>This is actually pretty funny:<br><br>On a workstation:<br><br>685 /usr/bin/pidgin<br>377 /usr/lib64/firefox/firefox<br>186 /usr/libexec/gconfd-2<br>94 /usr/lib64/vte/gnome-pty-helper<br>
60 /usr/bin/vim<br>
56 /usr/bin/pulseaudio<br>49 /usr/bin/mesg<br>36 /bin/sed<br>30 /bin/vi<br>10 /usr/libexec/gdm-session-worker<br>8 /usr/libexec/gnome-settings-daemon<br>5 /usr/lib64/libreoffice/program/soffice.bin<br>4 /usr/bin/less<br>
4 /usr/bin/ruby<br>4 /usr/bin/gnome-volume-control-applet<br>3 /usr/bin/evince<br>2 /usr/bin/vinagre<br>2 /usr/bin/gnome-panel<br>1 /sbin/rsyslogd<br><br></div>So, it looks like my biggest culprits are...PIdgin and Firefox<br>
<br><br></div>On a server:<br><br>Executable Summary Report<br>=================================<br>total file<br>=================================<br>63360 /usr/bin/ruby<br>202 /usr/bin/vim<br>55 /usr/sbin/sshd<br>36 /usr/bin/mesg<br>
25 /bin/chmod<br>7 /usr/bin/python<br>5 /bin/chown<br>3 /usr/bin/less<br>2 /usr/sbin/httpd<br>2 /bin/vi<br>1 /usr/bin/man<br>1 /bin/chgrp<br><br></div>Tracking down the hits on Ruby was interesting.<br><br></div>
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?<br>
<br></div><div>Even so, 202 hits on VIM is a lot of garbage when you start aggregating systems.<br></div><div><br></div>Thanks,<br><br></div>Trevor<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 10:54 AM, Steve Grubb <span dir="ltr"><<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wednesday, July 10, 2013 11:36:47 PM Trevor Vaughan wrote:<br>
> Unfortunately, I completely understand the threat.<br>
><br>
> I believe the threat to be: If we know when all of these happen, then we'll<br>
> be able to figure out who is trying to do what in case something bad<br>
> happens.<br>
><br>
> I completely get it, but that's a heck of a lot of garbage data 99% of the<br>
> time. I guess the real question is: Is the garbage data worth the 1%?<br>
<br>
</div>Where are you seeing all these permission changes and what is doing it? You<br>
gave a syscall report as evidence which is not helpful to understand what the<br>
issue is and how we might resolve it.<br>
<div class="im"><br>
<br>
> In response to Steve:<br>
><br>
> Wouldn't it be interesting to see a permission change in a user's home<br>
> directory to 777 followed by some 644's or more 755's? This happens far too<br>
> often to get around pesky noexec settings on /tmp ;-).<br>
<br>
</div>If you wanted it, this will get it for you:<br>
<br>
-a always,exit -S fchmodat -F dir=/home -F a2&0111 -F filetype=file -k mkexe<br>
-a always,exit -S fchmod,chmod -F dir=/home -F a1&0111 -F filetype=file -k mkexe<br>
<br>
But this will catch only a naive user. The truly crafty users have to be<br>
caught another way. I'm still experimenting on how to do that.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Steve<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> On Mon, Jul 1, 2013 at 9:04 PM, Jeffrey Blank <<a href="mailto:blank@eclipse.ncsc.mil">blank@eclipse.ncsc.mil</a>>wrote:<br>
> > I think it was based on some set of (possibly now outmoded) DoD policy.<br>
> ><br>
> > And so the relationship to threat may not be clear. The DISA folks are<br>
> ><br>
> > most likely to know where it came from. Perhaps they could chime in.<br>
> ><br>
> > Since it was originally written a while ago, prior to the transition to<br>
> > SRGs based on security controls in NIST 800-53, it's likely worth<br>
> > revisiting. If the OS SRG contains all the auditing rules necessary for a<br>
> > STIG, and there are no additional DoD requirements, then we should<br>
> > certainly be able to consider adjustment.<br>
> > This has the OS SRG reqs:<br>
> ><br>
> > <a href="http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MA" target="_blank">http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MA</a><br>
> > C1PublicProfile/><br>
> > On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb <<a href="mailto:sgrubb@redhat.com">sgrubb@redhat.com</a>> wrote:<br>
> >> On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:<br>
> >> > I've been running in compliance with this rule for quite some time now<br>
> >><br>
> >> and<br>
> >><br>
> >> > I'm noticing that the amount of noise that it produces is simply<br>
> >><br>
> >> outrageous.<br>
> >><br>
> >> > The suggestion is:<br>
> >> ><br>
> >> > At a minimum the audit system should collect file permission changes<br>
> >> > for<br>
> >> > all users and root. Add the following to "/etc/audit/audit.rules":<br>
> >> ><br>
> >> > -a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \<br>
> >> > -k perm_mod<br>
> >> ><br>
> >> > If the system is 64 bit then also add the following:<br>
> >> ><br>
> >> > -a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \<br>
> >> > -k perm_mod<br>
> >><br>
> >> And these rules are incomplete. You also need -S fchmod -S fchmodat -S<br>
> >> setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S<br>
> >> fremovexattr<br>
> >><br>
> >> > And here is the output of a normal workstation over about a week of<br>
> >><br>
> >> > auditing and normal usage:<br>
> >> This is not the output generated by the rule above. :-) To get that you<br>
> >> would<br>
> >> to run:<br>
> >><br>
> >> ausearch --start this-week -k perm_mod<br>
> >><br>
> >> What is more interesting than the syscall list you have below is the<br>
> >> files and<br>
> >> programs causing it<br>
> >><br>
> >> ausearch --start this-week -k perm_mod --raw | aureport -x --summary<br>
> >> and<br>
> >> ausearch --start this-week -k perm_mod --raw | aureport -f --summary<br>
> >><br>
> >> Personally, I don't think its terribly interesting to see permission<br>
> >> changes<br>
> >> in a user's home directory. You might want to know that permissions<br>
> >> changed on<br>
> >> the user's home dir, but its uninteresting for anything it contains.<br>
> >><br>
> >> I can certainly see this as interesting for system directories. Anyone<br>
> >> recall<br>
> >> what the threat was that this rule was watching for?<br>
> >><br>
> >> -Steve<br>
> >><br>
> >> > Syscall Summary Report<br>
> >> > ==========================<br>
> >> > total syscall<br>
> >> > ==========================<br>
> >> > 24907 chmod<br>
> >> > 15870 chown<br>
> >> > 11169 rename<br>
> >> > 7409 open<br>
> >> > 6462 fchmod<br>
> >> > 5290 fchown<br>
> >> > 3687 umount2<br>
> >> > 1443 setsid<br>
> >> > 1166 fsetxattr<br>
> >> > 869 removexattr<br>
> >> > 456 adjtimex<br>
> >> > 360 fchmodat<br>
> >> > 337 lchown<br>
> >> > 211 setuid<br>
> >> > 69 mkdir<br>
> >> > 63 setsockopt<br>
> >> > 33 unlink<br>
> >> > 22 setxattr<br>
> >> > 20 clone<br>
> >> > 19 execve<br>
> >> > 7 fchownat<br>
> >> > 7 mount<br>
> >> > 7 creat<br>
> >> > 4 close<br>
> >> > 4 ioctl<br>
> >> > 3 symlink<br>
> >> > 2 mknod<br>
> >> > 1 rmdir<br>
> >> > 1 lsetxattr<br>
> >> > 1 clock_settime<br>
> >> > 1 capset<br>
> >> ><br>
> >> > So, I get why this can be useful. But I'm not so sure that it's useful<br>
> >><br>
> >> to<br>
> >><br>
> >> > know that Pidgin dropped a new temp file every few minutes or that,<br>
> >> > each<br>
> >> > time I open a file (and write a temp file), that I did this as a normal<br>
> >> > user.<br>
> >> ><br>
> >> > I just can't see the practicality of going through those top three<br>
> >><br>
> >> calls on<br>
> >><br>
> >> > a regular basis.<br>
> >> ><br>
> >> > I'm not necessarily suggesting that this type of thing be dropped but<br>
> >><br>
> >> I'd<br>
> >><br>
> >> > like to understand how auditors won't fall into just ignoring them<br>
> >> > completely.<br>
> >> ><br>
> >> > Thoughts?<br>
> >> ><br>
> >> > Thanks,<br>
> >> ><br>
> >> > Trevor<br>
> >><br>
> >> _______________________________________________<br>
> >> scap-security-guide mailing list<br>
> >> <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
> >> <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
> ><br>
> > _______________________________________________<br>
> > scap-security-guide mailing list<br>
> > <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
> > <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Trevor Vaughan<br>Vice President, Onyx Point, Inc<br>(410) 541-6699<br><a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a><br><br>-- This account not approved for unencrypted proprietary information --
</div>