<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 &gt; 500 works unless you run the command through a sudo session. Then, your auid is &gt; 500 but your euid is &lt; 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&#39;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">&lt;<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>&gt;</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>
&gt; Unfortunately, I completely understand the threat.<br>
&gt;<br>
&gt; I believe the threat to be: If we know when all of these happen, then we&#39;ll<br>
&gt; be able to figure out who is trying to do what in case something bad<br>
&gt; happens.<br>
&gt;<br>
&gt; I completely get it, but that&#39;s a heck of a lot of garbage data 99% of the<br>
&gt; 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>
&gt; In response to Steve:<br>
&gt;<br>
&gt; Wouldn&#39;t it be interesting to see a permission change in a user&#39;s home<br>
&gt; directory to 777 followed by some 644&#39;s or more 755&#39;s? This happens far too<br>
&gt; 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&amp;0111 -F filetype=file  -k mkexe<br>
-a always,exit -S fchmod,chmod -F dir=/home -F a1&amp;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&#39;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>
&gt; On Mon, Jul 1, 2013 at 9:04 PM, Jeffrey Blank &lt;<a href="mailto:blank@eclipse.ncsc.mil">blank@eclipse.ncsc.mil</a>&gt;wrote:<br>
&gt; &gt; I think it was based on some set of (possibly now outmoded) DoD policy.<br>
&gt; &gt;<br>
&gt; &gt;  And so the relationship to threat may not be clear.  The DISA folks are<br>
&gt; &gt;<br>
&gt; &gt; most likely to know where it came from.  Perhaps they could chime in.<br>
&gt; &gt;<br>
&gt; &gt; Since it was originally written a while ago, prior to the transition to<br>
&gt; &gt; SRGs based on security controls in NIST 800-53, it&#39;s likely worth<br>
&gt; &gt; revisiting.  If the OS SRG contains all the auditing rules necessary for a<br>
&gt; &gt; STIG, and there are no additional DoD requirements, then we should<br>
&gt; &gt; certainly be able to consider adjustment.<br>
&gt; &gt; This has the OS SRG reqs:<br>
&gt; &gt;<br>
&gt; &gt; <a href="http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MA" target="_blank">http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MA</a><br>
&gt; &gt; C1PublicProfile/&gt;<br>
&gt; &gt; On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb &lt;<a href="mailto:sgrubb@redhat.com">sgrubb@redhat.com</a>&gt; wrote:<br>
&gt; &gt;&gt; On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:<br>
&gt; &gt;&gt; &gt; I&#39;ve been running in compliance with this rule for quite some time now<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; and<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt; I&#39;m noticing that the amount of noise that it produces is simply<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; outrageous.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt; The suggestion is:<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; At a minimum the audit system should collect file permission changes<br>
&gt; &gt;&gt; &gt; for<br>
&gt; &gt;&gt; &gt; all users and root. Add the following to &quot;/etc/audit/audit.rules&quot;:<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; -a always,exit -F arch=b32 -S chown -F auid&gt;=500 -F auid!=4294967295 \<br>
&gt; &gt;&gt; &gt; -k perm_mod<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; If the system is 64 bit then also add the following:<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; -a always,exit -F arch=b64 -S chown -F auid&gt;=500 -F auid!=4294967295 \<br>
&gt; &gt;&gt; &gt; -k perm_mod<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; And these rules are incomplete. You also need -S fchmod -S fchmodat -S<br>
&gt; &gt;&gt; setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S<br>
&gt; &gt;&gt; fremovexattr<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt; And here is the output of a normal workstation over about a week of<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt; auditing and normal usage:<br>
&gt; &gt;&gt; This is not the output generated by the rule above. :-) To get that you<br>
&gt; &gt;&gt; would<br>
&gt; &gt;&gt; to run:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; ausearch --start this-week -k perm_mod<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; What is more interesting than the syscall list you have below is the<br>
&gt; &gt;&gt; files and<br>
&gt; &gt;&gt; programs causing it<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; ausearch --start this-week -k perm_mod --raw | aureport -x --summary<br>
&gt; &gt;&gt; and<br>
&gt; &gt;&gt; ausearch --start this-week -k perm_mod --raw | aureport -f --summary<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Personally, I don&#39;t think its terribly interesting to see permission<br>
&gt; &gt;&gt; changes<br>
&gt; &gt;&gt; in a user&#39;s home directory. You might want to know that permissions<br>
&gt; &gt;&gt; changed on<br>
&gt; &gt;&gt; the user&#39;s home dir, but its uninteresting for anything it contains.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I can certainly see this as interesting for system directories. Anyone<br>
&gt; &gt;&gt; recall<br>
&gt; &gt;&gt; what the threat was that this rule was watching for?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; -Steve<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt; Syscall Summary Report<br>
&gt; &gt;&gt; &gt; ==========================<br>
&gt; &gt;&gt; &gt; total  syscall<br>
&gt; &gt;&gt; &gt; ==========================<br>
&gt; &gt;&gt; &gt; 24907  chmod<br>
&gt; &gt;&gt; &gt; 15870  chown<br>
&gt; &gt;&gt; &gt; 11169  rename<br>
&gt; &gt;&gt; &gt; 7409  open<br>
&gt; &gt;&gt; &gt; 6462  fchmod<br>
&gt; &gt;&gt; &gt; 5290  fchown<br>
&gt; &gt;&gt; &gt; 3687  umount2<br>
&gt; &gt;&gt; &gt; 1443  setsid<br>
&gt; &gt;&gt; &gt; 1166  fsetxattr<br>
&gt; &gt;&gt; &gt; 869  removexattr<br>
&gt; &gt;&gt; &gt; 456  adjtimex<br>
&gt; &gt;&gt; &gt; 360  fchmodat<br>
&gt; &gt;&gt; &gt; 337  lchown<br>
&gt; &gt;&gt; &gt; 211  setuid<br>
&gt; &gt;&gt; &gt; 69  mkdir<br>
&gt; &gt;&gt; &gt; 63  setsockopt<br>
&gt; &gt;&gt; &gt; 33  unlink<br>
&gt; &gt;&gt; &gt; 22  setxattr<br>
&gt; &gt;&gt; &gt; 20  clone<br>
&gt; &gt;&gt; &gt; 19  execve<br>
&gt; &gt;&gt; &gt; 7  fchownat<br>
&gt; &gt;&gt; &gt; 7  mount<br>
&gt; &gt;&gt; &gt; 7  creat<br>
&gt; &gt;&gt; &gt; 4  close<br>
&gt; &gt;&gt; &gt; 4  ioctl<br>
&gt; &gt;&gt; &gt; 3  symlink<br>
&gt; &gt;&gt; &gt; 2  mknod<br>
&gt; &gt;&gt; &gt; 1  rmdir<br>
&gt; &gt;&gt; &gt; 1  lsetxattr<br>
&gt; &gt;&gt; &gt; 1  clock_settime<br>
&gt; &gt;&gt; &gt; 1  capset<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; So, I get why this can be useful. But I&#39;m not so sure that it&#39;s useful<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; to<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt; know that Pidgin dropped a new temp file every few minutes or that,<br>
&gt; &gt;&gt; &gt; each<br>
&gt; &gt;&gt; &gt; time I open a file (and write a temp file), that I did this as a normal<br>
&gt; &gt;&gt; &gt; user.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; I just can&#39;t see the practicality of going through those top three<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; calls on<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt; a regular basis.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; I&#39;m not necessarily suggesting that this type of thing be dropped but<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I&#39;d<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt; like to understand how auditors won&#39;t fall into just ignoring them<br>
&gt; &gt;&gt; &gt; completely.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; Thoughts?<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; Thanks,<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; Trevor<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; _______________________________________________<br>
&gt; &gt;&gt; scap-security-guide mailing list<br>
&gt; &gt;&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt; &gt;&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; scap-security-guide mailing list<br>
&gt; &gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt; &gt; <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>