<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hey Shawn,<br>
      <br>
      I was thinking this trough last night - I was wondering if we can
      use checksums (sha256+) to determine if someone is using the
      "stock" configuration and replace it with a fully STIGed version -
      I'm thinking this would be best applicable to new installations of
      RHEL. I understand the need for  atomic fixes for pre-existing
      systems, where the SA has modified the defaults, but I can
      guarantee you that most people just want a STIG'ed box out of the
      gate on install. I'm just trying to think in terms of long term
      and short term goals - the quicker we can satisfy the majority of
      the users (the ones that want something STIG'ed out of the box)
      the better acceptance the product will have, the long term should
      be to modify things for the people that mucked with their
      configurations, which I'm arguing is a minority.<br>
       <br>
      I go back to Star Trek II: Wrath of Khan with Spock, "It is
      logical. The needs of the many outweigh<a
        href="http://www.imdb.com/name/nm0000638/?ref_=tt_trv_qu"><span
          class="character"></span></a>...the needs of the few<a
        href="http://www.imdb.com/name/nm0000559/?ref_=tt_trv_qu"><span
          class="character"></span></a>...or the one."  We need to get
      the ship out of danger, and then worry about the needs of the few.<br>
      <br>
      What do you think of my solution?<br>
      <br>
      -Frank<br>
      <br>
      On 10/03/2013 09:42 PM, Shawn Wells wrote:<br>
    </div>
    <blockquote cite="mid:524E1D1D.1000209@redhat.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 10/3/13 3:11 PM, <a
          moz-do-not-send="true" class="moz-txt-link-abbreviated"
          href="mailto:fcaviggi@redhat.com">fcaviggi@redhat.com</a>
        wrote:<br>
      </div>
      <blockquote cite="mid:524DC170.6010502@redhat.com" type="cite">All,

        <br>
        <br>
        As a starting point for writing remediation fixes in the SSG -
        so, I did the following: <br>
        <br>
            $ ls ~<i class="moz-txt-slash"><span class="moz-txt-tag">/</span>scap-security-guide/RHEL6/input/checks<span
            class="moz-txt-tag">/</span></i>*.xml | awk '{ print $1 }' |
        sed s/\.[^\.]*$// &gt; ~/checks <br>
            $ ls ~<i class="moz-txt-slash"><span class="moz-txt-tag">/</span>scap-security-guide/RHEL6/input/fixes<span
            class="moz-txt-tag">/</span></i>*.sh | awk '{ print $1 }' |
        sed s/\.[^\.]*$// &gt; ~/fixes <br>
            $ sdiff ~/fixes ~/checks | less <br>
        <br>
        There's fair a bit of work to be done for the fix
        remediations... <br>
        <br>
        Since I'm new to the project, I was wondering if there was any
        ideas or standards to how the SSG should distribute some of
        these fixes - for example - a wholesale replacement of the
        audit.rules and auditd.conf might be preferable than doing
        piecemeal sed's.</blockquote>
      <br>
      It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules
      /etc/audit.rules`, and that likely is the right choice during an
      initial provisioning process. But then SysAdmins tailor audit
      rules, the system evolves, and we need to evaluate the audit.rules
      file against specific auditing guidance items after the pristine
      audit.rules template is manipulated. <br>
      <br>
      So, if a single rule must be remediated, we can't blow away the
      whole audit.rules file. Super fun sed scripts it is =/<br>
      <br>
      <br>
      <blockquote cite="mid:524DC170.6010502@redhat.com" type="cite"> I
        also think the first script that needs to be run is to tar the
        current existing configurations (as a backup) before applying
        any fix just in case we do something that jacks the users
        modifications to the system. <br>
      </blockquote>
      <br>
      A prevailing thought has been to address backups once the
      remediations are finished, as we'll have a better handle for which
      files will need addressing. <br>
      <br>
      Forcing the backup (through XCCDF/OVAL) is tricky. One thought has
      been to create an OVAL check -- which is listed first in the
      profile -- which will *always* fail. The remediation for said OVAL
      would be to perform the backups. Anyone have a better idea? =/<br>
      <br>
      <blockquote cite="mid:524DC170.6010502@redhat.com" type="cite">
        Anyway, just trying to get an idea of how to proceed set some
        goals for my contributions. <br>
      </blockquote>
      <br>
      These are <i>really</i> good questions. Thanks for starting the
      conversation!<br>
      <br>
      <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>
    <br>
    <pre class="moz-signature" cols="72">-- 
Frank Caviggia
Consultant, Public Sector
<a class="moz-txt-link-abbreviated" href="mailto:fcaviggi@redhat.com">fcaviggi@redhat.com</a>
(M) (571) 295-4560</pre>
  </body>
</html>