<HTML><BODY>
<BR>
<BR>
I have one more minor contribution.<BR>
<BR>
In the past, there has only been one SCAP content per OS. With the introduction of multiple SCAP contents that could be applicable to a single system, I have had a desire to create a way to facilitate performing a scan with all applicable content in a simplified manner. I really liked the concept of the /etc/init.d/oscap-scan and /etc/sysconfig/oscap-scan setup. I contributed a minor change to these files in openscap, which are available in v1.2.0. I have also attached the init file for older versions (1.0.8). So with the init file change in place, it creates a means of walking through multiple scan configurations and applying each.<BR>
<BR>
So the attached zip includes oscap-scan configuration files for the new content I included. I also updated the spec file to package them in the rpm. The only further enhancement I could foresee is including a detection of the running OS in the spec file and only installing oscap-scan configuration files applicable to the OS (e.g. don't install the RHEL5 oscap-scan configuration file on RHEL6 or RHEL7).<BR>
<BR>
So with these changes in place, you can simply run 'service oscap-scan start' to scan and remediate your RHEL5 system, in addition to firefox, java, and webmin packages. All in one sweep.<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">Trey.Henefield@ultra-ats.com</a><BR>
Tel: +1 512 327 6795 ext. 647<BR>
Fax: +1 512 327 8043<BR>
Mobile: +1 512 541 6450<BR>
<BR>
<a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><BR>
<BR>
-----Original Message-----<BR>
From: Jan Lieskovsky [mailto:jlieskov@redhat.com] <BR>
Sent: Friday, December 05, 2014 6:07 AM<BR>
To: Trey Henefield; Shawn Wells<BR>
Subject: Re: SCAP Content ...<BR>
<BR>
Hey Trey, Shawn,<BR>
<BR>
----- Original Message -----<BR>
> From: "Shawn Wells" <shawn@redhat.com><BR>
> To: "Trey Henefield" <trey.henefield@ultra-ats.com><BR>
> Cc: "Jan Lieskovsky" <jlieskov@redhat.com><BR>
> Sent: Thursday, December 4, 2014 7:33:37 PM<BR>
> Subject: Re: SCAP Content ...<BR>
<BR>
Trey,<BR>
<BR>
I second to Shawn. From a brief look this is a really brilliant contribution.<BR>
Thanks a lot for it!<BR>
<BR>
> <BR>
> This is fantastic! Skimmed the approval text, will definitely review <BR>
> when I get time later today. Will approve the patch email when I see <BR>
> the request come through (there's often a delay between posting and <BR>
> when list moderators get the notice).<BR>
<BR>
Shawn, the email has now reached the queue (Date: December 4, 2014 6:46 PM,<BR>
Subject: scap-security-guide post from <a href="mailto:trey.henefield@ultra-ats.com">trey.henefield@ultra-ats.com</a> requires approval).<BR>
Please approve it.<BR>
<BR>
Regarding the inclusion - if you make a PR, I can review it. Or should you be busy today, just make the ticket & attach the zip to it. I can make a PR during weekend & you can review. Either way works for me [*].<BR>
<BR>
Thank you && Regards, Jan.<BR>
--<BR>
Jan iankko Lieskovsky / Red Hat Security Technologies Team<BR>
<BR>
[*] I could make a ticket & attach the zip Trey sent in different email as attachment to it.<BR>
But to make the inclusion process more transparent & for proper contribution attribution,<BR>
IMHO it will be better to wait till the email + the attachment reaches the SSG mailing list.<BR>
<BR>
> <BR>
> Shawn<BR>
> <BR>
> --<BR>
> Shawn Wells<BR>
> Director, Innovation Programs<BR>
> <a href="mailto:shawn@redhat.com">shawn@redhat.com</a> | 443.534.0130<BR>
> @shawndwells<BR>
> <BR>
> > On Dec 4, 2014, at 1:28 PM, Trey Henefield <BR>
> > <trey.henefield@ultra-ats.com><BR>
> > wrote:<BR>
> > <BR>
> > <BR>
> > <BR>
> > Finally got export approval.<BR>
> > <BR>
> > For your reference, here was the outcome of that:<BR>
> > <BR>
> > “Per our conversation, the SCAP content you are proposing below is <BR>
> > not subject to the EAR in accordance with 15 CFR 734.3(b)(3). It <BR>
> > may be released online without restriction.<BR>
> > <BR>
> > The above-referenced section of the EAR states that the following <BR>
> > items are not subject to the EAR:<BR>
> > <BR>
> > (3) Publicly available technology and software, except software <BR>
> > classified under ECCN 5D002 on the Commerce Control List, that:<BR>
> > (i) Are already published or will be published as described in § <BR>
> > 734.7 of this part;<BR>
> > (ii) Arise during, or result from, fundamental research, as <BR>
> > described in §<BR>
> > 734.8 of this part;<BR>
> > (iii) Are educational, as described in § 734.9 of this part;<BR>
> > (iv) Are included in certain patent applications, as described in § <BR>
> > 734.10 of this part.<BR>
> > <BR>
> > The SCAP content is based on two publicly available technology sources:<BR>
> > DISA’s STIGs and NIST’s SCAP formatting requirements. Both are publicly<BR>
> > available online without restriction. There has been no addition of<BR>
> > controlled, US technology involved in creating this content – from <BR>
> > an export standpoint, it is merely a translation from one format to another.<BR>
> > <BR>
> > There is no encryption involved in either the original content or <BR>
> > the end-product.<BR>
> > <BR>
> > DISA has posted equivalent SCAP content publicly on their website. <BR>
> > The only difference between that content and the content proposed <BR>
> > here is that this is based on more current (but still publicly <BR>
> > releasable) STIG content.”<BR>
> > <BR>
> > I have just posted my content to the group. But I believe it will <BR>
> > require moderator approval as it exceeds the 200KB limit.<BR>
> > <BR>
> > <BR>
> > Best regards,<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">Trey.Henefield@ultra-ats.com</a><BR>
> > Tel: +1 512 327 6795 ext. 647<BR>
> > Fax: +1 512 327 8043<BR>
> > Mobile: +1 512 541 6450<BR>
> > <BR>
> > <a href="http://www.ultra-ats.com" target="_blank">www.ultra-ats.com</a><BR>
> > <BR>
> > From: Shawn Wells [mailto:shawn@redhat.com]<BR>
> > Sent: Tuesday, November 18, 2014 11:54 AM<BR>
> > To: Trey Henefield; Jan Lieskovsky<BR>
> > Subject: Re: SCAP Content ...<BR>
> > <BR>
> > On 11/18/14, 12:17 PM, Trey Henefield wrote:<BR>
> > Hi Shawn,<BR>
> > I finally got approval to submit my content changes upstream. I <BR>
> > just wanted to give you a heads up that there will be allot of <BR>
> > wonderful changes coming your way soon.<BR>
> > In addition to changes to existing content for RHEL6, I have created <BR>
> > content for RHEL5, Firefox, Java, and Webmin. The RHEL5 content <BR>
> > currently supports RHEL4 and RHEL5, as well as CentOS4 and CentOS5. <BR>
> > I hope that’s ok, given the debate going on about CentOS.<BR>
> > I am currently getting my content in sync will all the current <BR>
> > changes in the repo. I branched off about a year ago.<BR>
> > So as soon as I am done with that, I will send it your way. Because <BR>
> > there are so many changes, I would prefer to send them to you zipped <BR>
> > up via email and allow you to upload them as you approve them. I hope that’s ok.<BR>
> > <BR>
> > That's awesome Trey! I've looped in Jan to keep him fully informed.<BR>
> > <BR>
> > Content for extra applications would be most interesting, especially <BR>
> > around Firefox and Java. Are these OS-specific configs (e.g. Firefox <BR>
> > on RHEL6) or applicable to Firefox on any version of RHEL? If <BR>
> > agnostic we'll want to create a new top-level directory, else place <BR>
> > the content within input/services (or somewhere appropriate).<BR>
> > <BR>
> > RHEL4 is EOL, so I don't particularly see a need to create a new <BR>
> > top-level directory for it. RHEL5 makes perfect sense, though. As <BR>
> > for CentOS vs RHEL... perhaps leaving off CPE tags for the rules <BR>
> > will suffice, vs creating a CentOS top-level directory.<BR>
> > <BR>
> > Note in the last year we moved the code to GitHub. You should be <BR>
> > able to set an "upstream" remote target to rebase against, e.g.:<BR>
> > <BR>
> > $ git remote add upstream<BR>
> > <a href="https://github.com/OpenSCAP/scap-security-guide.git" target="_blank">https://github.com/OpenSCAP/scap-security-guide.git</a><BR>
> > <BR>
> > Then once added:<BR>
> > $ git checkout master<BR>
> > $ git fetch upstream<BR>
> > $ git merge upstream/master<BR>
> > (this will likely cause a series of merge conflicts. send a note to <BR>
> > the list if you need some help merging!)<BR>
> > <BR>
> > In terms of patch review, if you're not comfortable with GitHub pull <BR>
> > requests (which is a bit convoluted, especially the required <BR>
> > branching), would you be willing to post them to the mailing list? <BR>
> > This would allow many more eyes during the review.<BR>
> > <BR>
> > Out of curiosity, how did you get your management approval to commit <BR>
> > back upstream? Any lessons learned we could reuse?<BR>
> > <BR>
> > <BR>
> > Disclaimer<BR>
> > The information contained in this communication from <BR>
> > <a href="mailto:trey.henefield@ultra-ats.com">trey.henefield@ultra-ats.com</a> sent at 2014-12-04 13:12:26 is private<BR>
> > and may be legally privileged or export controlled. It is intended <BR>
> > solely for use by <a href="mailto:shawn@redhat.com">shawn@redhat.com</a> and others authorized to receive<BR>
> > it. If you are not <a href="mailto:shawn@redhat.com">shawn@redhat.com</a> you are hereby notified that any<BR>
> > disclosure, copying, distribution or taking action in reliance of <BR>
> > the contents of this information is strictly prohibited and may be unlawful.<BR>
> > <BR>
> <BR>
<BR>
<BR>
<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" size="1" face="Verdana, Arial, Helvetica, sans-serif"><b>
trey.henefield@ultra-ats.com
</b> sent at
2014-12-08
13:22:52
is private and may be legally privileged or export controlled. It is intended solely for
use by <b>
scap-security-guide@lists.fedorahosted.org
</b> and others
authorized to receive it. If you are not <b>
scap-security-guide@lists.fedorahosted.org
</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>
</BODY></HTML>