[PATCH] [RFC] Modularized the fix scripts

Gary Gapinski Gapinski at nasa.gov
Thu Feb 21 12:26:28 UTC 2013


On 02/20/2013 10:37 PM, Francisco Slavin wrote:
> So the complexity of writing SCAP content is an issue that's been
> periodically raised in various parts of the community. Is anyone aware
> of what the current recommended best-practice is? I'm not so sure that
> solving the problem of overly-complex XML by adding yet another layer
> of XML is really solving the problem; at some point (usually
> troubleshooting) it just becomes added complexity.

My personal recommendation is to use a suitably-devised XML
representation (or as many as one needs) and transform via XSLT. XML is
not essential, just easier, particularly at the final stage that
produces SCAP-compliant documents. This does not preclude
representations other than XML — it's just more difficult to parse
non-XML on its way to becoming XML. This difficulty may simply be a
personal shortcoming. Use of XML also affords schema-driven content
editing. While they likely exist, I am unaware of any alternate syntaxes
that can coerce correctness at content creation time solely using static
documents in the fashion of XML schemata.

I cannot recommend any other recommendations, particularly any using
SCAP "languages" natively or via telekinesis.

Any departure from something simple that can be easily wielded by
someone whose expertise lies in system configuration rather than arcane
"languages" is wacky, which is the current state of affairs in SCAP.

> At some point early in our involvement with SCAP we mucked around with doing something similar, but with a non-XML-based domain-specific language called SC [1] (and its compiler, SCC.  This was before we knew there was a scanning tool out there of that name; early days, etc.).  The goal was to have a more human-readable syntax for authoring content which would then be compiled into OVAL.  At the time we hadn't started tackling XCCDF.  At some point I even rolled up an Eclipse plug-in to allow for auto-completion and dropdown-niceties for the SC language, though that plug-in never made it to a releasable state.

That sounds perfectly reasonable.

> The project itself is neither here nor there, but from past experience going down the road of "Let's add another authorship layer to make this easier" there are some pitfalls to look out for.  The primary one is the problem of testing your end-content that has been produced.  To drop into the narrative for a moment:
> So you [the content author/protagonist here] author your content in a simpler manner.  You have some auto-complete, the syntax is simple, life is good.  You then run some magic to get the end content compiled (or transformed via XSLT).  Now you've got your messy XCCDF/OVAL/whatever, but thanks to your easy-authorship approach you don't really have to look at that.  You test the content out in your tool-of-choice, but drat!  It didn't do what you expected.  What went wrong?  Was it:
>  A ) The original content you wrote has a bug
>  B ) The transform/compiler you leveraged has a bug
>  C ) The tool you leveraged has a bug
>
> In order to track this down you really need an in-depth knowledge of the XCCDF/OVAL.  That's what your tool is consuming, so to figure out if the problem is that content or if it's the tool requires really looking at the XCCDF/OVAL.  In order to debug content, your content author will still need to have some deep knowledge of XCCDF/OVAL.

Yes, particularly at C, and less likely at A if the original content is
not something wacky.

Were SCAP not a consideration, how much easier would this become?

> I'm sure everyone on this list has written a lot more XCCDF & OVAL than myself, so I'll defer to the community's expertise here.  I'm just not sure there's a practical way to avoid having XCCDF be levied on content authors; the best solution may be to just get a good editor UI set up.  I believe SCAP Workbench [2] takes that approach.

I think this can only be successful if OVAL were to disappear, and the X
in XCCDF actually lived up to its commitments.




More information about the scap-security-guide mailing list