From: Steve Grubb [mailto:email@example.com]
Sent: Friday, September 07, 2012 10:07 AM
Cc: Francisco Slavin
Subject: Re: SSG Audit + Aqueduct Remediation Linking
On Thursday, September 06, 2012 10:25:48 PM Francisco Slavin wrote:
> We are planning to continue using the <fix> tag with a custom system
> attribute string to indicate that the <fix> tag contains BASH
> content. We are currently considering JSON notation as the leading
> candidate for writing the <fix> content because it is both easy to
> and easy to parse. The information we want to make sure we cover
> for running a remediation script is:
One of the fundamental items that show up over and over is the
kickstart script for system installation. If you want to spin up a VM,
kickstart can be used. If you want to make a liveCD, kickstart again.
If you want to install a bare-metal system...you guessed it.
Please allow me to
clarify our target use case. We are not simply looking to use the scripts for a kickstart
to generate a compliant system at build-time. The goal of linking the remediation
directly in to the XCCDF is to be able to remediate a system throughout its lifecycle in
order to maintain compliance. Rolling a compliant system once was the original problem
addressed by previous iterations of CLIP. The development of SCAP standards has allowed
for compliance checking throughout a system's lifecycle, and the goal of integrating
remediation in with the XCCDF content is to assure compliance throughout a system's
The open scap tool can take the XCCDF docs and turn it into a
remediation script. You then add boiler plate at the top for
partitioning, language, time zone, etc...and you have a kickstart
Forgive my lack of familiarity here - if I'm reading this right, then what the oscap
tool is doing is simply pulling the content from the <fix> tags so that that content
can be directly appended to a kickstart? And thus use of JSON (or another format) in the
<fix> tag would make the oscap tool have to perform an additional parsing step?
I would be curious to see a content example from a <fix> tag that oscap can process.
Part of our goal for approaching the problem the way we've proposed is to allow for
remediation authors to be flexible in how they write their scripts. Thus we put in
provisions to support passing variables from the XCCDF content in to the remediation
scripts via positional arguments or environment variables. I believe this is compliant
with the SCAP vision of XCCDF as the policy language. All variables would be defined in
XCCDF, and those would get propagated down to the OVAL checks and to the remediation
scripts. Our current Aqueduct scripts have hard-coded values in them, and the goal is to
move away from that so that key variables are defined only once in the XCCDF policy
Are these goals something that you address in your vision of how <fix> tag content
is written and used?
I'd really like to keep things so that moving between XCCDF and
kickstart is simple.
One of our key reasons for choosing JSON markup was ease of
parsing. To move between XCCDF and kickstart would be slightly more difficult with the
addition of JSON, but it is not a costly parsing process or a particularly complex one. I
think it would require only minor updates to the oscap tool to be able to support this
approach. We are hoping to address the problem in a way that is not too burdensome on