<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"><<a href="mailto:trey.henefield@ultra-ats.com" target="_blank">trey.henefield@ultra-ats.com</a>></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'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 -> 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(".xml"):<br>
with open(sys.argv[2] + "/" + filename, 'r') as xml_file:<br>
body = body + xml_file.read()<br>
+<br>
+ for filename in os.listdir(sys.argv[3]):<br>
+ if filename.endswith(".xml"):<br>
+ with open(sys.argv[3] + "/" + filename, 'r') 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('SHARED_DIR')<br></div><div><br>for filename in os.listdir(sys.argv[2]):<br>
if filename.endswith(".xml"):<br></div><div>+ local_path = sys.argv[2] + "/" + 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 + "/oval/" + filename<br>- with open(sys.argv[2] + "/" + filename, 'r') as xml_file:<br>+ with open(xml_filename, 'r') 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 'shared_' 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 'make validate' 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'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>
> From: "Trey Henefield" <<a href="mailto:trey.henefield@ultra-ats.com" target="_blank">trey.henefield@ultra-ats.com</a>><br>
> To: "<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>" <br>
> <<a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a>><br>
> Sent: Wednesday, April 8, 2015 11:13:48 PM<br>
> Subject: Shared Checks/Fixes ...<br>
> <br>
> Greetings,<br>
> <br>
> <br>
> <br>
> I wanted to propose a change to the current structure in place for <br>
> shared checks (shared/oval) and fixes (shared/fixes/bash). I was <br>
> curious to get everyone’s opinion before committing.<br>
<br>
Thank you for opening this topic.<br>
<br>
> <br>
> <br>
> <br>
> So the problem I see is with the symbolic linking of checks and fixes <br>
> to the shared folder. I have found it problematic when working between <br>
> 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't been urgent need to fix this (to be read as so far there haven't been much reports current behaviour causing issues for developers).<br>
But as the count of the SCAP content products raises it's time to fix this.<br>
<br>
> <br>
> <br>
> <br>
> Rather than creating symbolic links to certain oval checks in the <br>
> shared/oval folder, we could choose to just process all oval checks in <br>
> 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'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'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't necessarily need to be working for all of the products having these checks (that's the case below mentioning there are shared/ OVAL checks used just for RHEL-7 & Fedora systems, while<br>
RHEL-6 version is different / RHEL-6 product specific).<br>
<br>
> <br>
> <br>
> <br>
> However, not all checks in the current ‘shared/oval’ folder are shared <br>
> by all OS. For example, there are some that only apply to RHEL7 and <br>
> Fedora, and not RHEL6.<br>
<br>
See the explanation above why that's the case.<br>
<br>
> <br>
> <br>
> <br>
> 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'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'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's OVAL check / fix present for that product, use that one. If there isn't and there's is symlink, use the /shared version. If there isn't even symlink, return no check / no fix available leading to 'notchecked' 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 &<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>
> <br>
> <br>
> <br>
> Thanks!<br>
> <br>
> <br>
> <br>
> Best regards,<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Trey Henefield, CISSP<br>
> <br>
> Senior IAVA Engineer<br>
> <br>
> <br>
> <br>
> Ultra Electronics<br>
> <br>
> Advanced Tactical Systems, Inc.<br>
> <br>
> 4101 Smith School Road<br>
> <br>
> Building IV, Suite 100<br>
> <br>
> Austin, TX 78744 USA<br>
> <br>
> <br>
> <br>
> <a href="mailto:Trey.Henefield@ultra-ats.com" target="_blank">Trey.Henefield@ultra-ats.com</a><br>
> <br>
> Tel: <a href="tel:%2B1%20512%20327%206795%20ext.%20647" value="+15123276795" target="_blank">+1 512 327 6795 ext. 647</a><br>
> <br>
> Fax: <a href="tel:%2B1%20512%20327%208043" value="+15123278043" target="_blank">+1 512 327 8043</a><br>
> <br>
> Mobile: <a href="tel:%2B1%20512%20541%206450" value="+15125416450" target="_blank">+1 512 541 6450</a><br>
> <br>
> <br>
> <br>
> <a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Disclaimer<br>
> The information contained in this communication from <br>
> <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>
> and may be legally privileged or export controlled. It is intended <br>
> solely for use by <a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a> and<br>
> others authorized to receive it. If you are not <br>
> <a href="mailto:scap-security-guide@lists.fedorahosted.org" target="_blank">scap-security-guide@lists.fedorahosted.org</a> you are hereby notified<br>
> that any disclosure, copying, distribution or taking action in <br>
> reliance of the contents of this information is strictly prohibited and may be unlawful.<br>
> <br>
> <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>
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>