I have one more minor contribution.

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.

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).

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.

Best regards,


Trey Henefield, CISSP
Senior IAVA Engineer

Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA

Trey.Henefield@ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450

www.ultra-ats.com

-----Original Message-----
From: Jan Lieskovsky [mailto:jlieskov@redhat.com]
Sent: Friday, December 05, 2014 6:07 AM
To: Trey Henefield; Shawn Wells
Subject: Re: SCAP Content ...

Hey Trey, Shawn,

----- Original Message -----
> From: "Shawn Wells" <shawn@redhat.com>
> To: "Trey Henefield" <trey.henefield@ultra-ats.com>
> Cc: "Jan Lieskovsky" <jlieskov@redhat.com>
> Sent: Thursday, December 4, 2014 7:33:37 PM
> Subject: Re: SCAP Content ...

Trey,

I second to Shawn. From a brief look this is a really brilliant contribution.
Thanks a lot for it!

>
> This is fantastic! Skimmed the approval text, will definitely review
> when I get time later today. Will approve the patch email when I see
> the request come through (there's often a delay between posting and
> when list moderators get the notice).

Shawn, the email has now reached the queue (Date: December 4, 2014 6:46 PM,
Subject: scap-security-guide post from trey.henefield@ultra-ats.com requires approval).
Please approve it.

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 [*].

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

[*] I could make a ticket & attach the zip Trey sent in different email as attachment to it.
But to make the inclusion process more transparent & for proper contribution attribution,
IMHO it will be better to wait till the email + the attachment reaches the SSG mailing list.

>
> Shawn
>
> --
> Shawn Wells
> Director, Innovation Programs
> shawn@redhat.com | 443.534.0130
> @shawndwells
>
> > On Dec 4, 2014, at 1:28 PM, Trey Henefield
> > <trey.henefield@ultra-ats.com>
> > wrote:
> >
> >
> >
> > Finally got export approval.
> >
> > For your reference, here was the outcome of that:
> >
> > “Per our conversation, the SCAP content you are proposing below is
> > not subject to the EAR in accordance with 15 CFR 734.3(b)(3). It
> > may be released online without restriction.
> >
> > The above-referenced section of the EAR states that the following
> > items are not subject to the EAR:
> >
> > (3) Publicly available technology and software, except software
> > classified under ECCN 5D002 on the Commerce Control List, that:
> > (i) Are already published or will be published as described in §
> > 734.7 of this part;
> > (ii) Arise during, or result from, fundamental research, as
> > described in §
> > 734.8 of this part;
> > (iii) Are educational, as described in § 734.9 of this part;
> > (iv) Are included in certain patent applications, as described in §
> > 734.10 of this part.
> >
> > The SCAP content is based on two publicly available technology sources:
> > DISA’s STIGs and NIST’s SCAP formatting requirements. Both are publicly
> > available online without restriction. There has been no addition of
> > controlled, US technology involved in creating this content – from
> > an export standpoint, it is merely a translation from one format to another.
> >
> > There is no encryption involved in either the original content or
> > the end-product.
> >
> > DISA has posted equivalent SCAP content publicly on their website.
> > The only difference between that content and the content proposed
> > here is that this is based on more current (but still publicly
> > releasable) STIG content.”
> >
> > I have just posted my content to the group. But I believe it will
> > require moderator approval as it exceeds the 200KB limit.
> >
> >
> > Best regards,
> >
> > Trey Henefield, CISSP
> > Senior IAVA Engineer
> >
> > Ultra Electronics
> > Advanced Tactical Systems, Inc.
> > 4101 Smith School Road
> > Building IV, Suite 100
> > Austin, TX 78744 USA
> >
> > Trey.Henefield@ultra-ats.com
> > Tel: +1 512 327 6795 ext. 647
> > Fax: +1 512 327 8043
> > Mobile: +1 512 541 6450
> >
> > www.ultra-ats.com
> >
> > From: Shawn Wells [mailto:shawn@redhat.com]
> > Sent: Tuesday, November 18, 2014 11:54 AM
> > To: Trey Henefield; Jan Lieskovsky
> > Subject: Re: SCAP Content ...
> >
> > On 11/18/14, 12:17 PM, Trey Henefield wrote:
> > Hi Shawn,
> > I finally got approval to submit my content changes upstream. I
> > just wanted to give you a heads up that there will be allot of
> > wonderful changes coming your way soon.
> > In addition to changes to existing content for RHEL6, I have created
> > content for RHEL5, Firefox, Java, and Webmin. The RHEL5 content
> > currently supports RHEL4 and RHEL5, as well as CentOS4 and CentOS5.
> > I hope that’s ok, given the debate going on about CentOS.
> > I am currently getting my content in sync will all the current
> > changes in the repo. I branched off about a year ago.
> > So as soon as I am done with that, I will send it your way. Because
> > there are so many changes, I would prefer to send them to you zipped
> > up via email and allow you to upload them as you approve them. I hope that’s ok.
> >
> > That's awesome Trey! I've looped in Jan to keep him fully informed.
> >
> > Content for extra applications would be most interesting, especially
> > around Firefox and Java. Are these OS-specific configs (e.g. Firefox
> > on RHEL6) or applicable to Firefox on any version of RHEL? If
> > agnostic we'll want to create a new top-level directory, else place
> > the content within input/services (or somewhere appropriate).
> >
> > RHEL4 is EOL, so I don't particularly see a need to create a new
> > top-level directory for it. RHEL5 makes perfect sense, though. As
> > for CentOS vs RHEL... perhaps leaving off CPE tags for the rules
> > will suffice, vs creating a CentOS top-level directory.
> >
> > Note in the last year we moved the code to GitHub. You should be
> > able to set an "upstream" remote target to rebase against, e.g.:
> >
> > $ git remote add upstream
> > https://github.com/OpenSCAP/scap-security-guide.git
> >
> > Then once added:
> > $ git checkout master
> > $ git fetch upstream
> > $ git merge upstream/master
> > (this will likely cause a series of merge conflicts. send a note to
> > the list if you need some help merging!)
> >
> > In terms of patch review, if you're not comfortable with GitHub pull
> > requests (which is a bit convoluted, especially the required
> > branching), would you be willing to post them to the mailing list?
> > This would allow many more eyes during the review.
> >
> > Out of curiosity, how did you get your management approval to commit
> > back upstream? Any lessons learned we could reuse?
> >
> >
> > Disclaimer
> > The information contained in this communication from
> > trey.henefield@ultra-ats.com sent at 2014-12-04 13:12:26 is private
> > and may be legally privileged or export controlled. It is intended
> > solely for use by shawn@redhat.com and others authorized to receive
> > it. If you are not shawn@redhat.com 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.
> >
>


Disclaimer
The information contained in this communication from
trey.henefield@ultra-ats.com 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 scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.org 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.