[RFC] time to move to github?

Jan Lieskovsky jlieskov at redhat.com
Thu Feb 20 10:30:24 UTC 2014


Hello Gary, Martin,

----- Original Message -----
> From: "Gary Gapinski" <gapinski at nasa.gov>
> To: scap-security-guide at lists.fedorahosted.org
> Sent: Wednesday, February 19, 2014 8:39:39 PM
> Subject: Re: [RFC] time to move to github?
> 
> On 02/19/2014 11:17 AM, Jeffrey Blank wrote:
> > I do not want a variety of government agencies
> > creating Frankenstein forks of scap-security-guide.
> 
> I am unsure whether this is worthy of a fork, but read on.
> 
> > I want them to use
> > the profiling mechanisms of XCCDF to select what they need from a single
> > high-quality dictionary of compliance checks (for each product for which
> > such content exists).  One of the unstated goals of the project is to
> > keep the variety of government compliance machines under some control by
> > providing a solution which meets >95% of use cases.
> 
> Our intent is to score a subset of all checklist items but have all
> items evaluated on all systems. This requires all¹ <Rule>s to be selected.

Gary, if I got your use case from this (and your subsequent email from today) correctly,
the request being as follows:
* on one hand to have a "profile / checklist" of all rules (grepped by their
  uniqueness) that ever existed for RHEL {6,7} products. All rules would be
  selected by default, and
* to have possibility to score only subset of them during scan

(feel free to correct me if I didn't the request details properly).

Projected into scap-workbench functionality this means:
* have possibility to merge various profiles (by grepping various but only
  unique rules),
* have possibility how to specify the subset of rules (within that resulting
  checklist) that should be scored during scan.

scap-workbench (SW) currently supports tailoring (e.g. a way how to select
subset of rules from particular profile into new one). From that implies
to me that the first point could be (possibly) reached with currently
supported SW functionality as follows:
1) Select particular profile. Use tailoring. Select all rules from it, and
   save it.
2) Load another profile in the "Profile:" field of the SW section, load the
   previously saved tailoring file, and click customize. Naive view suggests
   SW should in that scenario allow to add rules from the selected profile
   to the original tailoring (but didn't try it, so might be wrong)

   If not (Cc-ing Martin for hint on this), there should be a SW ticket:
     [1] https://fedorahosted.org/scap-workbench/newticket

   created for this enhancement (please note you need to be logged in to be
   able to file new SW ticket).

For what is worthy regarding selecting just of a subset of rules, that should
be scored during the scan, I don't think this is currently supported / possible
in SW (Martin pls correct me here too). => This would need another ticket to be
filed to cover this scenario.

To sum up:
* either "merging of rules" is currently supported in SW already, and you could
  perform as described above. Or an RFE should be filed for it this to be
  possible in the future (let me know, if I should file that ticket on your
  behalf),
* scoring subset of profile rules during scan would require new RFE ticket
  (again can file it on your behalf, just let me know).

The advantage of aforementioned approach (when compared to scap-security-guide
fork) being in case more users having same request / use case scenario as you, they
could profit from these (possibly new) SW features without needing to perform
additional steps (SSG fork & own XSLT transforms implementation).

Of course, all of the above depends on the fact if underlying standards /
scanner implementation allows this (needs deeper inspection). Stay tuned.

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

P.S.: Hopefully from the above being visible that (in my opinion) parser tools
      customizations are preferred way rather than SSG content forks (IOW agree with Jeffrey,
      that there should be one "core" content repository being able to
      handle various use-cases, rather than dozen of content forks, each
      of them bended to serve / handle particular instance expectations).

> 
> A <Profile> cannot alter the role² attribute of a <Rule> (to unscored
> rather than full).
> 
> We intend to do this using a modified benchmark containing a single
> <Profile>, and applying arbitrary "profiles" to the evaluation results
> at a subsequent time.
> 
> This is most easily done using a fork describing the necessary changes.
> A fork may also ease the task of having a single checklist for RHEL6 and
> RHEL7 comprised of parts common to both as well as parts peculiar to either.
> 
> Regards,
> 
> Gary
> 
> --
> ¹ Actually most, as we will not traipse through terabytes of local
> storage looking for unowned files, e.g.
> ² Goes back a ways:
> http://making-security-measurable.1364806.n2.nabble.com/role-unchecked-error-1-1-4-td1389041.html.
> _______________________________________________
> 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