<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 4/5/13 10:25 PM, Shawn Wells wrote:<br>
    </div>
    <blockquote cite="mid:515F879B.5000403@redhat.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 4/5/13 3:08 PM, Francisco Slavin
        wrote:<br>
      </div>
      <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C84CD@Exchange10.columbia.tresys.com"
        type="cite">
        <pre wrap="">So it might be my mail client, but I'm struggling to discern who is saying what in this thread.  I added in some &gt;&gt; indicators but may have gotten them wrong.</pre>
      </blockquote>
      fwiw, works in Thunderbird 17.0.5 and Zimbra.<br>
      <br>
      <br>
      <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C84CD@Exchange10.columbia.tresys.com"
        type="cite">
        <pre wrap="">On Friday, April 05, 2013 12:23 AM, Shawn Wells wrote:
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">On 3/29/13 3:08 PM, Aaron Lamb wrote:
I've been meaning to chime in on this topic but have been extremely busy as of late.
</pre>
          </blockquote>
          <pre wrap="">Thanks for taking time to contribute to the conversation! Many people seem to think commuting code is the only way to contribute; getting engaged in conversations is *extremely* valuable.
</pre>
        </blockquote>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">I have already been writing scripts based off the SSG output and slowly working towards something usable.  The main thing I have been working towards follows these 3 rules when it comes to remediation..  
</pre>
          </blockquote>
        </blockquote>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">1: If we need to change a file, make a time stamped copy before changing the file.  
2: If a file is modified, lets put a comment on what was done with a date and SSG Rule ID
3: Write stdout and stderr to a log file.  Whatever happens, I want to know about it.
</pre>
          </blockquote>
        </blockquote>
        <blockquote type="cite">
          <pre wrap="">I agree with the logic behind #3, however note that output is captured by OpenSCAP natively (thus the scripts don't need their own log files). Check out Simon Lukasik's awesome writeup here:
</pre>
        </blockquote>
        <pre wrap=""><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://isimluk.livejournal.com/3573.html">http://isimluk.livejournal.com/3573.html</a>
</pre>
        <blockquote type="cite">
          <pre wrap="">Specifically, the &lt;message&gt; tags within &lt;rule-result&gt;'s
</pre>
        </blockquote>
        <pre wrap="">For point #3 I disagree.  I think that the scripts themselves should not know or care where information is getting logged to.  Basic info should be written to stdout by default, error information should be written to stderr by default.  Tools such as the oscap tool can then capture this information and log it accordingly (possibly based on whether a user passes in a --verbose option or has different config options set).  I think that having one configuration point for logging will make the most sense in the long run and that point should be the tool consuming the content.  Thus is a tool provides the options you can configure logging however you like for your system:
I want my audit results to go to spot A
I want my remediation results to go to spot B
If verbose, capture the stdout information somewhere
If non-verbose, only capture the stderr information

I think we should have a more involved conversation about the approach to writing remediation content for SSG.  I will send a patch up momentarily (purely to facilitate this discussion) demonstrating how we were originally writing SSG-targeted scripts in Aqueduct [1].</pre>
      </blockquote>
      <br>
      EMails with [PATCH] in the subject line move to the top of my
      queue... Your patch makes much more sense after reading this!<br>
      <br>
      <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C84CD@Exchange10.columbia.tresys.com"
        type="cite">
        <pre wrap="">My concern is that there may be some clash between script-authorship best practices and SSG-content-authorship best practices.  From our quick conversation after the workshop it seems like Jeff and Shawn are both on the same page re: scripts should live directly in the &lt;fix&gt; tags when content hits a consuming system; they should not be kept in separate .sh files and reference from within the &lt;fix&gt; tag.  This poses a problem for authorship with regards to functional programming and code maintenance.
</pre>
      </blockquote>
      I know you and I have spoken of this, but as a clarification point
      (to avoid confusion of others), the location of scripts at <i>development</i>
      will be different than finished product. Within the project the
      RHEL6/input/fixes/bash/ directory houses the scripts, of which
      Make merges into the master XCCDF output. When saying content
      should live within the &lt;fix&gt; tags, the statement is
      regarding finished output.<br>
      <br>
      Full agreement on the challenges this may introduce, though.<br>
      <br>
      <blockquote
cite="mid:24EF0A937B77C942811D893DF06A28354C84CD@Exchange10.columbia.tresys.com"
        type="cite">
        <pre wrap="">As you will be able to see from the patches I forward over, we took the approach of grouping common tasks into one common function to perform those tasks and passing in parameters as appropriate for a particular fix.
This relied on having the common function in its own file and sourcing (the bash '.' operator) that file for specific fix-scripts.  This is basic programming best-practice to keep from copy/pasting code across multiple areas.
If all of the bash scripts will live within one XCCDF XML file, each in discrete &lt;fix&gt; tags, I'm not sure what approach the community would like to take regarding function re-use.  It seems like some pre-processing may be necessary; i.e. resolve the source operator before inserting the script content into the &lt;fix&gt; tag.  The goal is to only have one copy of a specific function saved in the SSG repo but to be able to use it for multiple &lt;fix&gt;es which differ only in one parameter.

It seems like a good time to start pushing these conversations given the recent questions popping up on the list.  Thoughts?</pre>
      </blockquote>
      Perhaps templates can be used, similar to the OVAL checks. For
      example the OVAL for checking package installation is here:<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/checks/templates/template_OVAL_package_installed">http://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/checks/templates/template_OVAL_package_installed</a><br>
      <br>
      The create_package_installed.py script replaces instances of
      PKGNAME with items listed here:<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/checks/templates/packages_installed.csv">http://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/checks/templates/packages_installed.csv</a><br>
      <br>
      And the whole process is managed by create_package_installed.py:<br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/checks/templates/create_package_installed.py">http://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/checks/templates/create_package_installed.py</a></blockquote>
    <br>
    Generated a sample patch:<br>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-April/002963.html">https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-April/002963.html</a><br>
    <br>
    This clearly won't solve all the code reuse challenges, but wanted
    to throw some code behind the idea to start the conversation. Such
    an approach would have a measurable impact on QA and
    supportability/maintenance. <br>
    <br>
    I also realized that I did not address your pre-processing comment.
    Since the SSG output is generated by a self inflected build process,
    there's an incredible amount of freedom to perform such a thing and
    hide it from content developers and users. What do you have in mind?<br>
  </body>
</html>