[PATCH] [RFC] Modularized the fix scripts

Francisco Slavin fslavin at tresys.com
Thu Feb 21 03:06:29 UTC 2013


On Wednesday, February 20, 2013 7:02 PM, Jeffrey Blank wrote:
> A few quick points:
> 1) Ditto on the exporting of variables to achieve flexibility with
> regard to values.  SecState may provide some inspiration, as I believe
> they populate environment variables to handle this (see Francisco's
> earlier post).  This will have to be addressed by tooling (and careful
> sync between tooling and content authors).  Presumably the openscap
> developers can cook up something in their fix-generation.

So I want to caveat that the way we do things in SecState [1] isn't necessarily robust enough for the level of content authorship/management that the community has now reached.  It was largely POC at the time to establish how simple it could be to implement such a mechanism.  We were simply populating 3 fields:
 1) A path to the script
 2) A set of environment variables to populate for the script
 3) A set of positional arguments to pass in to the script

I would like to point out that you cannot use arbitrary XML within the <fix> tag and have the content be valid XCCDF.  We went with using JSON in there for convenience.  The only accepted XML elements within that <fix> tag are a <sub> or <instance> tag, and the <sub> 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.

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?  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.


> 
> 2) I am concerned about the presence of what are effectively bash
> checking scripts in the fix tags.  In the presence of adequate tooling
> and SCAP checking content it seems unnecessary.  I also fear that this
> will divert effort away from QA on the OVAL content, which is the
> checking system used in baselines (and against which your systems would
> be "officially" scanned in most compliance regimes, including DoD's).
> I'm not trying to start a fun flamewar (again) and I don't disagree
> with
> Gary about OVAL deficiencies, and I also like the fact that SCE exists,
> I'm just saying that this project still has high-quality OVAL content
> as
> a goal.  And the point of formatting the script actions into <fix> tags
> is that they'd only be activated in case of check failure anyway.
> (Right?)  It is also a goal to simplify.
> 

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.

> Overall, I like much of Shawn's patch for fix content as a first step,
> and grant it an ACK (except for the script checking parts).  It seems
> like a reasonable place to start and we can iterate forward with
> OpenSCAP and Aqueduct and SecState developers.
> 

I've been a bit out-of-pocket lately with some other work & travel; it seems like every time I check in here the community is moving forward by leaps and bounds.  It's great to see this project hitting its goals.  I'll be prioritizing updates to SecState soon to pull in the latest OpenSCAP (with its shiny new high-level API), and then integrate the SecState updates in to CLIP along with new SSG content.  As I work through that you'll likely be hearing a lot more from me here.


> Another goal to keep in mind is how to link this to other types of
> remediation (or systems management) resources.
> 
> For example, I cannot really imagine Puppet modules or Ansible
> playbooks
> or Chef recipes living in scap-security-guide.  Ensuring that providers
> of such *very valuable* resources (which allow administrators to
> actually, uh, manage their systems instead of just do C&A and deploy
> them) can interoperate is worthwhile.
> 

I think that for this sort of <fix> branching keeping <fix> content itself outside of the XCCDF and referencing it is again going to be the way to go.  The XCCDF will be much more sane-looking if it has some pseudo-standard external references to BASH or puppet content as needed, as opposed to containing all of that content in one XCCDF document.  SecState originally supported Puppet for remediation (before the content authorship community took a heavy lean toward BASH).  We could use JSON to reference out to Puppet again if needed, it would simply be a different set of parameters.

[1] - https://fedorahosted.org/secstate/wiki/RemediationContentHowTo

 - Francisco




More information about the scap-security-guide mailing list