<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">I think the RPM is just really out of
      date.<br>
      <br>
      Hmmm, I'll look into the umask thing, but I was under the
      assumption that if one failed, the whole file should fail, so
      that's probably the reasoning behind never looking for a second
      umask value. Note that the prose guide section for each umask
      setting makes no attempt to distinguish between multiple places to
      change umask settings.<br>
      <br>
      I checked and noticed that admin_space_left and
      admin_space_left_action don't show up at all in the STIG. I also
      noticed that the title for the prose section describing
      admin_space_left_action is wrong in the SSG. I wonder if the
      variable name is also wrong and the check is looking for the wrong
      thing? I will check this tomorrow.<br>
      <br>
      I don't know where "ignoresyslogemailexecsuspendsinglehalt" is
      coming from. Grepping through the entire SSG reveals nothing. When
      I get in tomorrow, I'll try to track down what's happening (maybe
      regex gone wrong?).<br>
      <br>
      If you open up the XCCDF in a text editor, you'll notice that
      Rules will sometimes contain &lt;check&gt; tags. These check tags
      have nearly unreadable ids, BUT you will find them in
      ssg-rhel6-oval.xml with the same names and can get a human
      readable ref_id that will point you to the correct file in
      RHEL6/input/checks in the git repo.<br>
      <br>
      - Maura Dailey<br>
      <br>
      On 08/28/2013 04:52 PM, Robert Sanders wrote:<br>
    </div>
    <blockquote
      cite="mid:848FB1215E2AD643A5E10D906091D3FB692324@TCSEXCH1.tcs-sec.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
      <div style="direction: ltr;font-family: Tahoma;color:
        #000000;font-size: 10pt;">Maura,<br>
          I just pulled the latest git stuff down and made it all,
        zipped up all the 'ssg-' files from the output directory and
        dropped that on the SCC3.1 GA scanner.  A stock box had 6 passes
        and 5 failures out of total of 388 items.  After locking it down
        with SB I went to 5 passes and 6 failures (yep - wrong way) out
        of 388.  Operator error on making the packages ?<br>
        <br>
          Couple of interesting questions on the results (after scan):<br>
        <br>
        <br>
        <br>
          Set default bash umask (ditto for csh and default umask)<br>
            Examing the indicated files shows there are two places where
        the umask could be set, one for 002 and one for 022, with the
        UID of the caller determining which is used.  The scanner is
        catching the first instance. 
        <br>
        <br>
          Configure Auditd for space_left and admin_space_left:<br>
            In both cases I inspected the /etc/audit/auditd.conf file
        and verify that the required line is present according to the
        prose. I do notice that the list of appropriate actions appears
        to be a single 'word' set to be:<br>
        <br>
           ignoresyslogemailexecsuspendsinglehalt<br>
        <br>
        Not sure what is going on under the hood to know if these are
        being glommed together for the prose but kept separate for the
        OVAL checks or not.<br>
        <br>
        I need to try and rerun with the SCC rc6 beta, but may not have
        time today...<br>
        <br>
        -Rob<br>
          <br>
        <br>
        <br>
        <br>
          <br>
        <br>
        <br>
        <div style="font-family: Times New Roman; color: rgb(0, 0, 0);
          font-size: 16px;">
          <hr tabindex="-1">
          <div style="direction: ltr;" id="divRpF529901"><font
              color="#000000" face="Tahoma" size="2"><b>From:</b>
              <a class="moz-txt-link-abbreviated" href="mailto:scap-security-guide-bounces@lists.fedorahosted.org">scap-security-guide-bounces@lists.fedorahosted.org</a>
              [<a class="moz-txt-link-abbreviated" href="mailto:scap-security-guide-bounces@lists.fedorahosted.org">scap-security-guide-bounces@lists.fedorahosted.org</a>] on
              behalf of Maura Dailey [<a class="moz-txt-link-abbreviated" href="mailto:maura@eclipse.ncsc.mil">maura@eclipse.ncsc.mil</a>]<br>
              <b>Sent:</b> Wednesday, August 28, 2013 1:05 PM<br>
              <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
              <b>Subject:</b> Re: Various False Positives?<br>
            </font><br>
          </div>
          <div>
            <div class="moz-cite-prefix">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 "RHEL-06-000". These are all marked as fail but
                  the server meets the STIG.<br>
                </div>
              </div>
            </blockquote>
            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'm seeing the same results, and I've made a
            lot of changes to OVAL checks in the git repository in the
            past few weeks. I'm going to run through your list,
            comparing it against the OVAL checks.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>  9   rhnsd can be on if configured to Satellite
                  server or similar<br>
                </div>
              </div>
            </blockquote>
            Fix text definitely implies this. It's not the only service
            that implies it's allowed in certain environments, but then
            proceeds to only accept a value of disabled.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div> 57   ucredit <br>
                </div>
                <div> 58   ocredit<br>
                </div>
                <div> 59   lcredit<br>
                </div>
              </div>
            </blockquote>
            For the previous 3, I'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'd like to
            see your exact /etc/issue so I can debug what went wrong. If
            it's an exact copy of the text from the STIG, I'll work off
            that.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div> 98  No ipv6 installed<br>
                </div>
              </div>
            </blockquote>
            Do you mean it's disabled on your system, but the OVAL
            checks are saying it isn't?<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div> 99  "<br>
                </div>
              </div>
            </blockquote>
            ?<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>
            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't gotten to testing audit checks yet. Maybe this is
            broken. I'll check it out once I've deciphered the OVAL
            check.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>171  clock_settime<br>
                </div>
                <div>184-196, 200 chmod, chown, etc...<br>
                </div>
              </div>
            </blockquote>
            Haven't tested audit checks yet...<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>206-211  No telnet installed or turned on<br>
                </div>
              </div>
            </blockquote>
            These are both automated checks. Unless the package name is
            wrong, I don't know why they'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.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>271  If there are no removable partitions this is
                  not a finding.<br>
                </div>
              </div>
            </blockquote>
            Working on testing this one now...<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>
            Agreed, the GNOME checks need to be rewritten to have
            extended definitions to exclude machines that don't have X
            installed.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>326   "  <br>
                </div>
              </div>
            </blockquote>
            ?<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>346  Finding reported on umask 022<br>
                </div>
              </div>
            </blockquote>
            This is DEFINITELY a bug. The check section is actually
            pointing to a different check. The actual check for this
            rule was never written.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>348  No vsftp installed, thus no file.<br>
                </div>
              </div>
            </blockquote>
            No OVAL check exists in SSG.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>506  "hushlogin"<br>
                </div>
              </div>
            </blockquote>
            This one isn't in the SSG at all.<br>
            <blockquote type="cite">
              <div dir="ltr">
                <div>507  PrintLastLog<br>
                </div>
              </div>
            </blockquote>
            This one isn't in the SSG at all.<br>
            <br>
            - Maura Dailey<br>
            <br>
            <blockquote type="cite">
              <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 moz-do-not-send="true"
                        href="http://leamhall.blogspot.com/"
                        target="_blank">Mind on a Mission</a></div>
                  </div>
                </div>
              </div>
              <br>
              <fieldset class="mimeAttachmentHeader" target="_blank"></fieldset>
              <br>
              <pre>_______________________________________________
scap-security-guide mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" 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>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
scap-security-guide mailing list
<a class="moz-txt-link-abbreviated" href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>