<div dir="ltr">Hey Maura!<br><br>I&#39;m using the openscap-utils rpm and the content from the Fedorahosted zip file.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 28, 2013 at 1:05 PM, Maura Dailey <span dir="ltr">&lt;<a href="mailto:maura@eclipse.ncsc.mil" target="_blank">maura@eclipse.ncsc.mil</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>On 08/28/2013 12:04 PM, leam hall
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Hey all,<br>
          <br>
        </div>
        <div>Just ran oscap with the xml files available on the website
          (Benchmark version 0.9). Here are the issues that seem to be
          false positives. Prefix everything with &quot;RHEL-06-000&quot;. These
          are all marked as fail but the server meets the STIG.<br>
        </div>
      </div>
    </blockquote></div>
    Stupid question, but what are you running against exactly? The RPM
    or the latest git checkout? I want to make sure that if I run this,
    I&#39;m seeing the same results, and I&#39;ve made a lot of changes to OVAL
    checks in the git repository in the past few weeks. I&#39;m going to run
    through your list, comparing it against the OVAL checks.<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>  9   rhnsd can be on if configured to Satellite server or
          similar<br>
        </div>
      </div>
    </blockquote></div>
    Fix text definitely implies this. It&#39;s not the only service that
    implies it&#39;s allowed in certain environments, but then proceeds to
    only accept a value of disabled.<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div> 57   ucredit <br>
        </div>
        <div> 58   ocredit<br>
        </div>
        <div> 59   lcredit<br>
        </div>
      </div>
    </blockquote></div>
    For the previous 3, I&#39;d like to see the pam_cracklib.so line so I
    can troubleshoot.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div> 73   /etc/issue<br>
        </div>
      </div>
    </blockquote>
    Going back to my many many OVAL check updates, I&#39;d like to see your
    exact /etc/issue so I can debug what went wrong. If it&#39;s an exact
    copy of the text from the STIG, I&#39;ll work off that.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div> 98  No ipv6 installed<br>
        </div>
      </div>
    </blockquote>
    Do you mean it&#39;s disabled on your system, but the OVAL checks are
    saying it isn&#39;t?<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
           99  &quot;<br>
        </div>
      </div>
    </blockquote>
    ?<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>165  adjtimex<br>
        </div>
        <div>167  settimeofday<br>
        </div>
        <div>169  stime  // Also, the STIG is wrong. There is no x86_64
          stime syscall<br>
        </div>
      </div>
    </blockquote></div>
    The STIG actually says that stime is not necessary, which is kind of
    a strange wording, but the suggested line in the fix text prose is
    correct, at least. So far as OVAL checks go, I haven&#39;t gotten to
    testing audit checks yet. Maybe this is broken. I&#39;ll check it out
    once I&#39;ve deciphered the OVAL check.<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>171  clock_settime<br>
        </div>
        <div>184-196, 200 chmod, chown, etc...<br>
        </div>
      </div>
    </blockquote></div>
    Haven&#39;t tested audit checks yet...<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
        </div>
        <div>206-211  No telnet installed or turned on<br>
        </div>
      </div>
    </blockquote></div>
    These are both automated checks. Unless the package name is wrong, I
    don&#39;t know why they&#39;d give false positives.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>240  /etc/ssh/sshd_config Banner<br>
        </div>
      </div>
    </blockquote>
    The OVAL check was definitely working on my system when I last
    tested it.<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>271  If there are no removable partitions this is not a
          finding.<br>
        </div>
      </div>
    </blockquote></div>
    Working on testing this one now...<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>278  If the file permissions are more restrictive then it
          is not a finding.<br>
        </div>
        <div>324  No X running<br>
        </div>
      </div>
    </blockquote></div>
    Agreed, the GNOME checks need to be rewritten to have extended
    definitions to exclude machines that don&#39;t have X installed.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>326   &quot;  <br>
        </div>
      </div>
    </blockquote>
    ?<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>346  Finding reported on umask 022<br>
        </div>
      </div>
    </blockquote></div>
    This is DEFINITELY a bug. The check section is actually pointing to
    a different check. The actual check for this rule was never written.<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>348  No vsftp installed, thus no file.<br>
        </div>
      </div>
    </blockquote></div>
    No OVAL check exists in SSG.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>506  &quot;hushlogin&quot;<br>
        </div>
      </div>
    </blockquote>
    This one isn&#39;t in the SSG at all.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>507  PrintLastLog<br>
        </div>
      </div>
    </blockquote>
    This one isn&#39;t in the SSG at all.<br>
    <br>
    - Maura Dailey<br>
    <br>
    <blockquote type="cite"><div class="im">
      <div dir="ltr">
        <div>
          <br>
        </div>
        <div><br>
        </div>
        <div>Am I confused in thinking a system in run level 3 should
          net need to worry about X/Gnome findings?<br>
          <br>
        </div>
        <div>Leam<br>
        </div>
        <div>
          <div><br>
            -- <br>
            <div><a href="http://leamhall.blogspot.com/" target="_blank">Mind
                on a Mission</a></div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div><pre>_______________________________________________
scap-security-guide mailing list
<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a>
</pre>
    </blockquote>
    <br>
  </div>

<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></blockquote></div><br><br clear="all"><br>-- <br><div><a href="http://leamhall.blogspot.com/" target="_blank">Mind on a Mission</a></div>
</div>