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  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
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
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
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
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
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.
 - https://fedorahosted.org/secstate/wiki/RemediationContentHowTo