This afternoon sgrubb sent over where one could RTFM on the Fedora EPEL build system (thanks, Steve!). I was able to perform scratch builds in koji (the Fedora build system) tonight:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6008567
While the SSG RPM builds, several errors are thrown during rpmlint validation. The RHEL6/transforms/xccdf2table-* files need to issue proper HTML headers, e.g. "<!DOCTYPE html>"
I'll be locked into meetings over the next two days, and I believe Dave & Jeff will be too. If anyone is feeling ambitious, patches to start resolving these errors would be INCREDIBLY helpful to move the project towards having a legitimate RPM in EPEL!
[shawn@localhost scap-security-guide]$ make clean ; \ make all ; \ rpmlint rpmbuild/src/redhat/RPMS/noarch/scap-security-guide-0.1-12.el6.noarch.rpm ....... ....... scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/policytables/table-rhel6-nistrefs.html scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/eap5-oval.xml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/policytables/table-rhel6-cces.html scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/eap5-xccdf.xml scap-security-guide.noarch: E: wrong-script-end-of-line-encoding /usr/share/xml/scap/ssg/content/eap5-xccdf.xml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/eap5-cpe-dictionary.xml scap-security-guide.noarch: E: wrong-script-end-of-line-encoding /usr/share/xml/scap/ssg/content/eap5-cpe-dictionary.xml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/ssg-rhel6-cpe-oval.xml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/policytables/table-rhel6-srgmap.html scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/policytables/table-rhel6-nistrefs-common.html scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/policytables/table-rhel6-srgmap-flat.html scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/guide/rhel6-guide.html scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/ssg-rhel6-xccdf.xml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/ssg-rhel6-oval.xml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/eap5-ocil.xml scap-security-guide.noarch: E: wrong-script-end-of-line-encoding /usr/share/xml/scap/ssg/content/eap5-ocil.xml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/guide/JBossEAP5_Guide.html scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/policytables/table-rhel6-srgmap-flat.xhtml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/ssg-rhel6-cpe-dictionary.xml scap-security-guide.noarch: E: script-without-shebang /usr/share/xml/scap/ssg/content/eap5-cpe-oval.xml
----- Original Message -----
This afternoon sgrubb sent over where one could RTFM on the Fedora EPEL build system (thanks, Steve!). I was able to perform scratch builds in koji (the Fedora build system) tonight:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6008567
While the SSG RPM builds, several errors are thrown during rpmlint validation. The RHEL6/transforms/xccdf2table-* files need to issue proper HTML headers, e.g. "<!DOCTYPE html>"
I'll be locked into meetings over the next two days, and I believe Dave & Jeff will be too. If anyone is feeling ambitious, patches to start resolving these errors would be INCREDIBLY helpful to move the project towards having a legitimate RPM in EPEL!
It might make sense to submit your package for EPEL and Fedora, not just EPEL. That should help prevent having to do this again once Fedora content is ready.
I'd be happy to review the request once you submit it (presuming nobody else wants to do it).
Hey Josh, Shawn, SSG contributors,
----- Original Message -----
From: "Josh Bressers" bressers@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Tuesday, October 1, 2013 2:29:45 PM Subject: Re: Any RPM builders? request for help legitimizing EPEL RPM
----- Original Message -----
This afternoon sgrubb sent over where one could RTFM on the Fedora EPEL build system (thanks, Steve!). I was able to perform scratch builds in koji (the Fedora build system) tonight:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6008567
While the SSG RPM builds, several errors are thrown during rpmlint validation. The RHEL6/transforms/xccdf2table-* files need to issue proper HTML headers, e.g. "<!DOCTYPE html>"
I'll be locked into meetings over the next two days, and I believe Dave & Jeff will be too. If anyone is feeling ambitious, patches to start resolving these errors would be INCREDIBLY helpful to move the project towards having a legitimate RPM in EPEL!
@Shawn && fixing RHEL6 rpmlint issues - wasn't around on Monday, and yesterday was question of get in touch with mails. Will have a look and RHEL-6 *.spec issues, and submit a patch proposal.
It might make sense to submit your package for EPEL and Fedora, not just EPEL. That should help prevent having to do this again once Fedora content is ready.
I'd be happy to review the request once you submit it (presuming nobody else wants to do it).
@more common plane regarding the future Fedora SCAP content direction - we have had a meeting with Brno Security Technologies guys yesterday, and since to ask the right question being an half-way answer, inlining the points we concluded at below and awaiting your feedback:
The milestones have been set up as follows: ------------------------------------------- #1 to have Fedora SSG SCAP rpm functionality available (DONE), #2 submit Fedora rpm package for review (PENDING), [for the beginning particular skeleton rules to be supported by OCIL recommendations], #3 increase the amount of rules and remediation scripts implemented (ITERATIVE PROCESS), #4 make a blog post regarding building SSG SCAP content for Fedora.
To dive more deeply into particular areas / points: ---------------------------------------------------
# regarding having RHEL6/JBossEAP5 SSG content available in Fedora package (this reasonable requirement [sample scenario: being able to scan RHEL6 VM system on my Fedora host] was actually raised right from the beginning, and i wanted to include the content later in the release cycle, but since you opened this topic, will react on this).
Motivation: =========== So the expectation is to have SSG content to have same package name (scap-security-guide) in both (Red Hat Enterprise Linux 6 && Fedora products), so RHEL6 users accustomed to use SSG functionality for scanning their systems wouldn't need to get familiar / accustomed to new things.
Proposal: ========= So instead of packaging current RHEL6 / JBossEAP5 rpm content as scap-security-guide rpm package into Fedora, we would rather prefer to modify existing Fedora rpm's spec file it to include the RHEL6 / JBossEAP5 content (possibly in form of subpackages) too.
The subpackages could be divided based on product (one for RHEL6, the another for JBossEAP5), or they could be separated based on profiles (AKA one particular package for each of the following ones: "common", "desktop", "server", "stig-rhel6-server", [possibly "CS2", "usgcb-rhel6-server" ones too]) - feedback on preferred subpackages separation form appreciated.
# regarding quick launch of Fedora SCAP SSG content:
Vision #A: ---------- Keep adding OVAL rules and remediation scripts in progressive way putting emphasis on fact, each newly added rule to be complete in the moment of submit ('complete' in the sense there would be underlying OVAL rule and remediation script for it where possible already available).
But since this is time consuming process (main bottleneck has been identified to be the need to test the rules and remediation scripts on various systems to confirm they to return reasonable results for the different systems / configurations), we would prefer the Vision #B approach first / from the beginning.
Vision #B: ---------- Instead of trying to have all currently submitted XML rules they to have their counterparts in the form of OVAL rules and SCAP remediation scripts to be available in the moment of XML rule submit (AKA the XML rule to be 'complete'), we might want to submit only XML rules text content (and provide manual in the form of OCIL recommendations) for them first.
This would allow us to have form of more complete Fedora SCAP SSG guide sooner (no need to in a time consuming way to test the rules and corresponding SCAP remediation scripts). Also, this way Fedora system administrators would have a security guide available at hand sooner, and in the case they would want to apply the system remediations / hardenings / recommendations, listed in that guide, they could do it manually for now based on the provided OCIL recommendations / guidance.
Iteratively, in subsequent Fedora SCAP SSG RPM package versions, we would provide OVAL rules and SCAP remediation scripts for already documented XML definitions (here is space for Fedora community to start providing implementations [for not existing] or fixes [for already existing] code).
Again, feedback on the alternate visions above (or new proposals), welcome.
# regarding involvement of other Linux distributions into the SSG SCAP effort (the listing below should not be read as an exhaustive Linux / BSD distribution list, rather than like an example of other distributions, which are doing same / similar things, and representatives of which could be contacted to start contributing to upstream SSG project rules applicable to their distribution [since more heads know more things :), and at the end the effort could result only into the final product being more perfect]):
Sven Vermeulen of Gentoo: http://wiki.gentoo.org/wiki/User:SwifT seems to be participating on Gentoo's SCAP content: http://dev.gentoo.org/~swift/docs/security_benchmarks/ http://dev.gentoo.org/~swift/docs/security_benchmarks/gentoo.html http://www.gentoo.org/doc/en/security/security-handbook.xml
therefore we could probably get in touch with him / them, Gentoo to start participating on this effort / hosting their security content on the upstream SSG project too.
To mention other distributions for possible cooperation: https://help.ubuntu.com/10.04/serverguide/security.html http://www.debian.org/doc/manuals/securing-debian-howto/ http://doc.opensuse.org/documentation/html/openSUSE/opensuse-security/
For the three above unsure of status of upstream SSG project effort.
BSD ones: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/securing-freebsd.h... https://www.netbsd.org/docs/
..(many more here)..
This could be parallel goal / effort with the two aforementioned ones (benefit = profit on wider inter-distribution cooperation wrt to building security guidance documents).
Feedback welcome again.
Hopefully i have covered all the main points / conclusions from the yesterday's discussion. If not / will come with something yet i forgot to mention, will reply to this thread.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Sorry for such a long post again, but too much ideas / proposals to share (hopefully i didn't hijack the original topic too far).
-- Josh Bressers / Red Hat Product Security Team _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jan Lieskovsky -
Josh Bressers -
Shawn Wells