[PATCH] [RFC] Modularized the fix scripts

Jeffrey Blank blank at eclipse.ncsc.mil
Sun Feb 24 17:09:50 UTC 2013


> tag is basically just a reference to a <value> somewhere.  I know
> I've caught some flack for the JSON usage, but it was a practical way
> to get things implemented.  Given that we can't use arbitrary XML to
> keep the document all-XML, and that whatever we do within a <fix> tag
> ends up being pseudo-standard at best, JSON has proven to be a
> lightweight option for use as an intermediate solution.

We can do whatever we want with XML in our authoring language, and we're
not writing in any particular schema (as Gary has pointed out).  As far
as I'm concerned, final output should be valid XCCDF, but you can do
anything you want with XML until then.  (And tooling that prepares the
fixes for execution can take care of preparing the environment to run
the bash script, such as instantiating environment variables.)

And your perception is correct: attempts to introduce JSON (or Perl)
into SSG should expect serious resistance.  Had we started all
development in JSON, then I'd say the same about XML.


> I know there was a discussion about having a better way to uniquely
> identify fixes besides just a path to a script on a system.  Possibly
> some UUID which in turn maps to a script somewhere?  

I want fixes to identify what they're for (by referencing a Rule id),
not the other way around.  What <fix> to run is not the concern of the
baseline or guidance creator, and remediation is not the raison d'etre
of scap-security-guide.  But we're happy to work closely together and
include simple bash fixes inside the project.

In essence, I would encourage remediation developers to refer to items
in the input/system and input/services (and input/profiles) directories,
and develop tooling that permits combination and integration with the
content generated from there.

> If there's a
> standards-based way to do this it would be great, but with how
> immature the <fix> aspect of XCCDF is I'm not sure if that option is
> there.  Having some pseudo-standard in place here gives us
> flexibility to add fields or metadata as needed without invalidating
> the XCCDF document, whereas if there were raw BASH content in the
> <fix> tag we would not have that sort of flexibility.

My motivation to look into the "right" way to do remediation will be far
higher when someone can assure me that the OVAL has actually been QA'ed.
 Could you advise on current status of this?  Is this still a dependency
of CLIP?


> I'll chime in again with an opinion that I think BASH and non-XCCDF
> content should live in files external to the XCCDF, and simply be
> referenced from the XCCDF.  

Absolutely!  Like we do now in SSG, for development.

I'm assuming there will be one XCCDF file from SSG with simple bash
fixes, and one without.  In fact, that reminds me to adjust the Makefile
so that what is perceived as the "main" one does not include fixes.


> I'll chime in again with an opinion that I think BASH and non-XCCDF
> content should live in files external to the XCCDF, and simply be
> referenced from the XCCDF.  I know this is a discussion that's been
> had a few times, and this may be a battle I've already lost, so kick
> me if I shouldn't be bringing this back up.


Definitely -- no development of <fix> tags is occurring inline with the
main content. The fix tags live inside their own directories away from
where the usual XCCDF content is written.

I don't expect issuers of baselines to include <fix> tags, and the act
of adding fixes is intentionally seperable/separated.  It may be
possible to ship one version of the XCCDF file with bash fixes, and some
tooling may be able to process this, but this shouldn't preclude any
other approaches.


More information about the scap-security-guide mailing list