Hey Josh, Shawn, SSG contributors,
----- Original Message -----
From: "Josh Bressers" <bressers(a)redhat.com>
To: scap-security-guide(a)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-freebs...
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide