<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 9, 2015 at 8:04 AM, Trey Henefield <span dir="ltr">&lt;<a href="mailto:trey.henefield@ultra-ats.com" target="_blank">trey.henefield@ultra-ats.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <br>
    <br>
    Thank you everyone for the responses!<br>
<br>
I completely agree with the benefits of the shared directory. That really wasn&#39;t so much my concern, but rather a better way of utilizing it.<br>
<br>
As Jan pointed out, I am using a mixed Windows/Linux environment, making it challenging to maintain the symbolic links when traversing different filesystems (NTFS -&gt; EXT).<br>
<br>
So far, I have looked at some minor adjustments that can be made to shared/transforms/combinechecks.py and shared/transforms/combinefixes.py.<br>
<br>
I have tried adding an additional parameter through the Makefile to point to the $(SHARED)/oval folder and adding the following to shared/transforms/combinechecks.py:<br>
<br>
for filename in os.listdir(sys.argv[2]):<br>
        if filename.endswith(&quot;.xml&quot;):<br>
            with open(sys.argv[2] + &quot;/&quot; + filename, &#39;r&#39;) as xml_file:<br>
                body = body + xml_file.read()<br>
+<br>
+    for filename in os.listdir(sys.argv[3]):<br>
+        if filename.endswith(&quot;.xml&quot;):<br>
+            with open(sys.argv[3] + &quot;/&quot; + filename, &#39;r&#39;) as xml_file:<br>
+                body = body + xml_file.read()<br>
</div></blockquote><div><br></div><div>You could do it this way for combinechecks.py:<br><br></div><div>+ SHARED = os.environ.get(&#39;SHARED_DIR&#39;)<br></div><div><br>for filename in os.listdir(sys.argv[2]):<br>    
        if filename.endswith(&quot;.xml&quot;):<br></div><div>+         local_path = sys.argv[2] + &quot;/&quot; + filename<br></div><div>+         if not os.path.islink(local_path):<br></div><div>+             xml_filename = local_path<br></div><div>+         else:<br></div><div>+             xml_filename = SHARED + &quot;/oval/&quot; + filename<br>-          with open(sys.argv[2] + &quot;/&quot; + filename, &#39;r&#39;) as xml_file:<br>+         with open(xml_filename, &#39;r&#39;) as xml_file:</div><div><br></div><div>Then add the following to the Makefile(s):<br><br></div><div>export SHARED_DIR=$(SHARED)<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
This has the proper effect of adding all project-specific checks first, then adding in all shared checks. If there is a shared check with the same name as a project-specific check, the shared check will be excluded in favor of the project-specific check. Although, I personally think the identifier of each shared check should be prefaced with &#39;shared_&#39; to help identify it as a shared check. This could help to prevent duplicate IDs in any case.<br>
<br>
The downside of the above code though is that it adds all oval checks in the shared folder to the oval output of a specific project. It builds fine. But &#39;make validate&#39; complains about oval checks not being included in the XCCDF profile. There should be a better way to filter xml file content added from the shared folder to just those specific to the project&#39;s supported platform.<br>
<br>
As Shawn has hinted, this could perhaps be resolved in some XSLT magic. Are there any XSLT magicians out there? ;) This is a language I have yet to conquer.<span class=""><br>
<br>
Best regards,<br>
 <br>
<br>
Trey Henefield, CISSP<br>
Senior IAVA Engineer<br>
<br>
Ultra Electronics<br>
Advanced Tactical Systems, Inc.<br>
4101 Smith School Road<br>
Building IV, Suite 100<br>
Austin, TX 78744 USA<br>
<br>
<a href="mailto:Trey.Henefield@ultra-ats.com" target="_blank">Trey.Henefield@ultra-ats.com</a><br>
Tel: <a href="tel:%2B1%20512%20327%206795%20ext.%20647" value="+15123276795" target="_blank">+1 512 327 6795 ext. 647</a><br>
Fax: <a href="tel:%2B1%20512%20327%208043" value="+15123278043" target="_blank">+1 512 327 8043</a><br>
Mobile: <a href="tel:%2B1%20512%20541%206450" value="+15125416450" target="_blank">+1 512 541 6450</a><br>
<br>
<a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><br>
<br></span><span class="">
-----Original Message-----<br>
From: <a href="mailto:scap-security-guide-bounces@lists.fedorahosted.org" target="_blank">scap-security-guide-bounces@lists.fedorahosted.org</a> [mailto:<a href="mailto:scap-security-guide-bounces@lists.fedorahosted.org" target="_blank">scap-security-guide-bounces@lists.fedorahosted.org</a>] On Behalf Of Jan Lieskovsky<br>
Sent: Thursday, April 09, 2015 7:31 AM<br>
To: SCAP Security Guide<br>
Subject: Re: Shared Checks/Fixes ...<br>
<br></span><div><div class="h5">
Hello Trey,<br>
<br>
----- Original Message -----<br>
&gt; From: &quot;Trey Henefield&quot; &lt;<a href="mailto:trey.henefield@ultra-ats.com" target="_blank">trey.henefield@ultra-ats.com</a>&gt;<br>
&gt; To: &quot;<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>&quot; <br>
&gt; &lt;<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>&gt;<br>
&gt; Sent: Wednesday, April 8, 2015 11:13:48 PM<br>
&gt; Subject: Shared Checks/Fixes ...<br>
&gt; <br>
&gt; Greetings,<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; I wanted to propose a change to the current structure in place for <br>
&gt; shared checks (shared/oval) and fixes (shared/fixes/bash). I was <br>
&gt; curious to get everyone’s opinion before committing.<br>
<br>
  Thank you for opening this topic.<br>
<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; So the problem I see is with the symbolic linking of checks and fixes <br>
&gt; to the shared folder. I have found it problematic when working between <br>
&gt; different operating systems, file systems, and version control systems.<br>
<br>
  Right from the beginning we knew the concept of symbolic links will introduce issues when dealing with SSG content across multiple OS versions.<br>
But so far there hasn&#39;t been urgent need to fix this (to be read as so far there haven&#39;t been much reports current behaviour causing issues for developers).<br>
But as the count of the SCAP content products raises it&#39;s time to fix this.<br>
<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Rather than creating symbolic links to certain oval checks in the <br>
&gt; shared/oval folder, we could choose to just process all oval checks in <br>
&gt; both the project’s checks folder and the shared/oval folder.<br>
<br>
The original idea behind introducing /shared directory was the following - when trying to identify corresponding OVAL check for particular XCCDF rule the following scheme should be applied:<br>
* when there&#39;s is OVAL check for that product present in input/checks<br>
  directory for that product, this OVAL check should be used with priority,<br>
* when there isn&#39;t, use the corresponding (equally named) OVAL check from<br>
  shared/ directory.<br>
<br>
During the time we advanced the idea / concept even more in the sense that shared/ version of OVAL checks doesn&#39;t necessarily need to be working for all of the products having these checks (that&#39;s the case below mentioning there are shared/ OVAL checks used just for RHEL-7 &amp; Fedora systems, while<br>
RHEL-6 version is different / RHEL-6 product specific).<br>
<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; However, not all checks in the current ‘shared/oval’ folder are shared <br>
&gt; by all OS. For example, there are some that only apply to RHEL7 and <br>
&gt; Fedora, and not RHEL6.<br>
<br>
See the explanation above why that&#39;s the case.<br>
<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Any thoughts?<br>
<br>
If I should attempt to summary:<br>
* the concept of shared/ checks has proven to be beneficial (in the sense it&#39;s<br>
  less work to keep just one concrete copy updated than try to keep updated multiple<br>
  identical copies),<br>
* the mechanism of symbolic links is not the way to go (since it&#39;s known not to work<br>
  e.g. on Microsoft Windows OS systems),<br>
<br>
So IMHO we want to keep the shared/ OVAL checks / fixes concept, but implement it different way. Maybe as already suggested by modificating the build process to look not just into CWD for OVAL check / remediation fix, but also to look into particular subdirectory of shared/ directory (OVAL checks vs fixes) simultaneously with preserving priority (if there&#39;s OVAL check / fix present for that product, use that one. If there isn&#39;t and there&#39;s is symlink, use the /shared version. If there isn&#39;t even symlink, return no check / no fix available leading to &#39;notchecked&#39; state).<br>
<br>
HTH<br>
<br>
Regards, Jan.<br>
--<br>
Jan iankko Lieskovsky / Red Hat Security Technologies Team<br>
<br>
P.S.: As the count of products we produce SCAP content for is only going to<br>
      raise in the future, IMHO concept of /shared directory for OVAL checks &amp;<br>
      fixes can only save us a lot of duplicate work in the future (when compared<br>
      to the scenario of managing multiple copies of the same file on per product<br>
      basis).<br>
<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Thanks!<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Best regards,<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Trey Henefield, CISSP<br>
&gt; <br>
&gt; Senior IAVA Engineer<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Ultra Electronics<br>
&gt; <br>
&gt; Advanced Tactical Systems, Inc.<br>
&gt; <br>
&gt; 4101 Smith School Road<br>
&gt; <br>
&gt; Building IV, Suite 100<br>
&gt; <br>
&gt; Austin, TX 78744 USA<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <a href="mailto:Trey.Henefield@ultra-ats.com" target="_blank">Trey.Henefield@ultra-ats.com</a><br>
&gt; <br>
&gt; Tel: <a href="tel:%2B1%20512%20327%206795%20ext.%20647" value="+15123276795" target="_blank">+1 512 327 6795 ext. 647</a><br>
&gt; <br>
&gt; Fax: <a href="tel:%2B1%20512%20327%208043" value="+15123278043" target="_blank">+1 512 327 8043</a><br>
&gt; <br>
&gt; Mobile: <a href="tel:%2B1%20512%20541%206450" value="+15125416450" target="_blank">+1 512 541 6450</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Disclaimer<br>
&gt; The information contained in this communication from <br>
&gt; <a href="mailto:trey.henefield@ultra-ats.com" target="_blank">trey.henefield@ultra-ats.com</a> sent at 2015-04-08 17:13:55 is private<br>
&gt; and may be legally privileged or export controlled. It is intended <br>
&gt; solely for use by <a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a> and<br>
&gt; others authorized to receive it. If you are not <br>
&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a> you are hereby notified<br>
&gt; that any disclosure, copying, distribution or taking action in <br>
&gt; reliance of the contents of this information is strictly prohibited and may be unlawful.<br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; SCAP Security Guide mailing list<br>
&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a><br>
&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
&gt; <a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a><br>
--<br>
SCAP Security Guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">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>
<a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a><br>

    <br>
    <br>
 </div></div><p><font size="1"><b><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif">Disclaimer</font></b><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif"><br>
        The information contained in this communication from </font></font><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif" size="1"><b>
          <a href="mailto:trey.henefield@ultra-ats.com" target="_blank">trey.henefield@ultra-ats.com</a>
          </b> sent at
          2015-04-09
          10:04:14
          is private and may be legally privileged or export controlled. It is intended solely for 
          use by <b>
            <a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>
            </b> and others 
          authorized to receive it. If you are not <b>
            <a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>
            </b> you are hereby notified that any disclosure, copying, distribution or 
          taking action in reliance of the contents of this information is strictly 
          prohibited and may be unlawful.</font><br>
          <br>
    </p></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>
<a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a><br></blockquote></div><br></div></div>