Any RPM builders? request for help legitimizing EPEL RPM

Jan Lieskovsky jlieskov at redhat.com
Wed Oct 2 09:50:16 UTC 2013


Hey Josh, Shawn, SSG contributors,

----- Original Message -----
> From: "Josh Bressers" <bressers at redhat.com>
> To: scap-security-guide at 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.html
    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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> 


More information about the scap-security-guide mailing list