<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 3/26/13 12:18 AM, Francisco Slavin
      wrote:<br>
    </div>
    <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C68C5@Exchange10.columbia.tresys.com"
      type="cite">
      <div class="moz-text-plain" wrap="true" graphical-quote="true"
        style="font-family: -moz-fixed; font-size: 12px;"
        lang="x-unicode">
        <pre wrap="">You rang?  Or, y'know, whatever sound emails make.  The internet is obviating the need for the onomatopoeia.</pre>
      </div>
    </blockquote>
    <br>
    I still envision the AOL "you've got mail!"<br>
    <br>
    Anyway....<br>
    <br>
    <br>
    <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C68C5@Exchange10.columbia.tresys.com"
      type="cite">
      <div class="moz-text-plain" wrap="true" graphical-quote="true"
        style="font-family: -moz-fixed; font-size: 12px;"
        lang="x-unicode">
        <pre wrap="">On Monday, March 25, 2013 10:15 PM, Shawn Wells wrote: 
</pre>
        <blockquote type="cite" style="color: #000000;">
          <pre wrap=""><span class="moz-txt-citetags">&gt; </span>I've been taking a few off-list questions around remediation lately, namely
<span class="moz-txt-citetags">&gt; </span>from interested parties asking "where do we start?" Wanted to move those
<span class="moz-txt-citetags">&gt; </span>conversations to on-list. Here's a few of the common questions and my
<span class="moz-txt-citetags">&gt; </span>thoughts to get us started.
<span class="moz-txt-citetags">&gt; </span>
</pre>
        </blockquote>
        <pre wrap="">I feel like I wade into this conversation from time to time and end up repeating myself a bit.  A couple past threads [1] for context [2] should keep me from being too repetitive.

</pre>
        <blockquote type="cite" style="color: #000000;">
          <pre wrap=""><span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>(1) What language(s) should be used?
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>IMO, bash. I'm leaning this way because it's included in <b class="moz-txt-star"><span class="moz-txt-tag">*</span>every<span class="moz-txt-tag">*</span></b> RHEL
<span class="moz-txt-citetags">&gt; </span>release, whereas puppet modules would require the installation of 3rd party
<span class="moz-txt-citetags">&gt; </span>software. I'd like to see as much done through 'native' tools as possible.
<span class="moz-txt-citetags">&gt; </span>There's certainly advantages to Perl (e.g., potential speed) however I don't
<span class="moz-txt-citetags">&gt; </span>think we want to assume Perl is installed on all RHEL machines.
<span class="moz-txt-citetags">&gt; </span>
</pre>
        </blockquote>
        <pre wrap="">Puppet 's high-level language lets you statefully define system configurations.  This is nice considering ostensibly XCCDF follows a very similar modeling approach.  The problem is government applicability - Puppet is in EPEL and is not enterprise-supported as such the last I checked, so for some areas it's simply not an option.  Additionally some people targeting embedded environments don't want to pull Puppet in.
BASH is everywhere and as such makes the most sense.
>From a tools side it would make sense to support numerous 'fix' mechanisms, and from a content side it may make sense to have fix content in various formats.  For the first steps it seems like BASH is the way to go.</pre>
      </div>
    </blockquote>
    <br>
    Personally I'm with you regarding puppet. Additionally RH has
    publicly stated plans to incorporate puppet into future (layered)
    products. However, as you pointed out, we can reasonably *depend* on
    bash being installed on any given RHEL box.<br>
    <br>
    As for additional formats, the extensibility is already built into
    the SSG build process (sample content for puppet exists). The
    challenge -- as you seemed also to identify -- is what the first
    steps will be. I worry about finding ourselves in a situation with
    fragmented remediation content... a few bash fixes, a few puppet.
    I'd rather pick one to begin with (and bash seems most logical).<br>
    <br>
    <br>
    <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C68C5@Exchange10.columbia.tresys.com"
      type="cite">
      <div class="moz-text-plain" wrap="true" graphical-quote="true"
        style="font-family: -moz-fixed; font-size: 12px;"
        lang="x-unicode">
        <blockquote type="cite" style="color: #000000;">
          <pre wrap=""><span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>(2) Do we perform checking in the scripts?
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Defined further, should the scripts contain conditional checks to see if they
<span class="moz-txt-citetags">&gt; </span>should be ran?
<span class="moz-txt-citetags">&gt; </span>IMO, no. That's what OVAL is for.
<span class="moz-txt-citetags">&gt; </span>
</pre>
        </blockquote>
        <pre wrap="">This conversation gets a bit muddied by the definition of 'checking'.  The fix scripts should not be written to check system state at the granularity targeted by OVAL checks.  But they should still be doing basic error checking and error handling.  As such they would need to report errors and the tool calling out to the fix scripts would have to act on them, so some common dictionary of return code values may be useful.  Using CEE has been brought up in the past as well.  Basically whichever front-end is calling out to SCAP libraries for check content gets its fine-grained error reporting taken care of thanks to those libraries; but the fix side will be done ad-hoc and having granular error reporting would still be a huge benefit.  The quick-and-dirty way would simply be to have 'success' and 'fail' RCs defined and to capture the stderr and stdout of the script according to whether it passes or fails, and what degree of logging your tool is set to (debug!
 /verbose/e
tc.).  This last approach is what SecState is currently doing.</pre>
      </div>
    </blockquote>
    I like the stderr/stout approach. Simon Lukasik recently wrote a
    good posting about how this output would be captured in result XML:<br>
    <a class="moz-txt-link-freetext" href="http://isimluk.livejournal.com/3573.html">http://isimluk.livejournal.com/3573.html</a><br>
    <br>
    <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C68C5@Exchange10.columbia.tresys.com"
      type="cite">
      <div class="moz-text-plain" wrap="true" graphical-quote="true"
        style="font-family: -moz-fixed; font-size: 12px;"
        lang="x-unicode">
        <blockquote type="cite" style="color: #000000;">
          <pre wrap=""><span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>(3) Where do we begin?
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>- Name remediation scripts after corresponding XCCDF rule
<span class="moz-txt-citetags">&gt; </span>- Build process includes them into final ssg-rhel6-xccdf.xml
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Known challenge on passing XCCDF variables through to the scripts,
<span class="moz-txt-citetags">&gt; </span>however I wouldn't let this hold us up. Still <b class="moz-txt-star"><span class="moz-txt-tag">*</span>tons<span class="moz-txt-tag">*</span></b> of work to be done
<span class="moz-txt-citetags">&gt; </span>while this gets sorted.
<span class="moz-txt-citetags">&gt; </span>
</pre>
        </blockquote>
        <pre wrap="">I'm not sure what challenge you're referencing here.  We've gotten variable passing to work pretty simply [3].

</pre>
        <blockquote type="cite" style="color: #000000;">
          <pre wrap=""><span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>There's a good bit of RHEL6 content in the Aqueduct project that (I
<span class="moz-txt-citetags">&gt; </span>believe) Tresys committed. Perhaps we could reuse those scripts?
<span class="moz-txt-citetags">&gt;</span>
</pre>
        </blockquote>
        <pre wrap="">The Tresys CLIP team did contribute a lot of scripts to Aqueduct which were written specifically to go alongside SSG SCAP content [4].  These scripts were mapped back directly to SSG rules [5].  They were written against an older version of the SSG repo and as such likely need a bit of an update, but I think they would be a very good starting place.

There are a lot of design concerns to keep in mind when approaching remediation content and the balance between authorship time and effort must be considered for each of those.  Unfortunately I missed the registration for your SCAP workshop this time around, but I would be happy to support a call to talk through some of this.
</pre>
      </div>
    </blockquote>
    <br>
    I'll need to dig deeper into your final output, but can you help me
    understand how your JSON gets transformed into valid XML?<br>
    <br>
    e.g.:<br>
    <blockquote type="cite">
      <meta charset="utf-8">
      <pre class="wiki" style="background-color: rgb(247, 247, 247); border: 1px solid rgb(215, 215, 215); margin: 1em 1.75em; padding: 0.25em; overflow: auto; color: rgb(0, 0, 0); font-size: 12.800000190734863px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-position: initial initial; background-repeat: initial initial;">&lt;!-- We use JSON notation to articulate a bash script call --&gt;
&lt;fix system="urn:xccdf:fix:script:bash"&gt;
        {
                "script" : "/root/passreqs.sh",
                 "environment-variables" : { "login_defs_min_len" : "&lt;sub idref="pass-min-length-var" /&gt;" },
                 "positional-args" : ["argument1", "argument2"]
        }
&lt;/fix&gt;</pre>
    </blockquote>
    <br>
    I'm imaging we'd need to modify the makefile to parse all this,
    sucking in $script and performing some kind of variable
    substitution. How do you guys handle things?<br>
    <br>
    <br>
    <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C68C5@Exchange10.columbia.tresys.com"
      type="cite">
      <div class="moz-text-plain" wrap="true" graphical-quote="true"
        style="font-family: -moz-fixed; font-size: 12px;"
        lang="x-unicode">
        <pre wrap="">
Thank you
 - Francisco

[1] Sep 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-September/001516.html">https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-September/001516.html</a>
[2] Feb 2013 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-February/002722.html">https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-February/002722.html</a>
[3] SecState XCCDF variable passing - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/secstate/wiki/RemediationContentHowTo">https://fedorahosted.org/secstate/wiki/RemediationContentHowTo</a>
[4] - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG">https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG</a>
[5] - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG/tools/fix_mapper.py">https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG/tools/fix_mapper.py</a>

</pre>
      </div>
    </blockquote>
    ##<br>
  </body>
</html>