SSG Audit + Aqueduct Remediation Linking

[Francisco Slavin]

Hello,

As you may be aware, one of the key use cases for SecState has been automated remediation.  We have shifted away from Puppet remediation to BASH remediation in response to community input & direction.  At this time our core target is enabling users to use SSG content to audit a system and Aqueduct content to remediate a system.  As we move forward with designing the "glue" to link the content together we would appreciate input from the community about the approach we're planning for this.  We want to help find an approach for this which is agreeable to the content maintainers and lets us meet our use cases.

We are planning to continue using the <fix> tag with a custom system attribute string to indicate that the <fix> tag contains BASH remediation content.  We are currently considering JSON notation as the leading candidate for writing the <fix> content because it is both easy to write and easy to parse.  The information we want to make sure we cover for running a remediation script is:

* Path to the script
 * Environment variables to define
 * Positional arguments to pass in to the script

Using JSON notation in a <fix> tag, this would be the representation of that info:

<fix system="urn:xccdf:fix:script:bash">
{
    "script" : "/usr/libexec/ssg/scripts/remediate_foo.sh"
    "environment-variables" : {"FOO" : "12", "TEST" : "<sub idref="xccdf_variable_foo" />"}
    "positional-args" : ["test","<sub idref=" other_xccdf_variable" />"]
}
</fix>

The array of positional-args would be assumed to be ordered.  So this example would call:
FOO=12 TEST=<value of xccdf_variable_foo> /bin/bash /usr/libexec/ssg/scripts/remediate_foo.sh test <value of other_xccdf_variable>

We would appreciate any input & feedback regarding this approach.

Thank you
- Francisco Slavin

[Steve Grubb]

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 remediation
> content.  We are currently considering JSON notation as the leading
> candidate for writing the <fix> content because it is both easy to write
> 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.

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

I'd really like to keep things so that moving between XCCDF and kickstart is 
simple.

-Steve

[Francisco Slavin]

> -----Original Message-----
> From: Steve Grubb [mailto:[e-mail]]
> Sent: Friday, September 07, 2012 10:07 AM
> To: [e-mail]
> 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
>
> remediation
> > content.  We are currently considering JSON notation as the leading 
> > candidate for writing the <fix> content because it is both easy to
>
> write
> > 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 lifecycle.
> 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 
> file.

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

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 tool developers.

Thank you
 - Francisco
> -Steve

[Jeffrey Blank]

I think it might make more sense to do it in XML instead of JSON.
Mixing JSON and XML makes one's eyes bleed in two different ways instead
of one way.  But I suppose it's parseable and transformable either way.

Have you given though to making it look (a little bit) like what's in
the CRE spec for a cre_entry (pg 25)?
http://csrc.nist.gov/publications/drafts/nistir-7831/Draft-NISTIR-7831.pdf

But perhaps in a more-convenient-for-human-editing format (something for
which automated transformation may be possible to CRE)?

Structurally this is reminiscent of Apple's plist XML schema (as it is
also designed to hierarchically store arbitrary key-value pairs, and
directly in XML).

On 09/06/2012 06:25 PM, Francisco Slavin wrote:
> Hello,
>
> As you may be aware, one of the key use cases for SecState has been
> automated remediation.  We have shifted away from Puppet remediation
> to BASH remediation in response to community input & direction.  At
> this time our core target is enabling users to use SSG content to
> audit a system and Aqueduct content to remediate a system.  As we
> move forward with designing the "glue" to link the content together
> we would appreciate input from the community about the approach we're
> planning for this.  We want to help find an approach for this which
> is agreeable to the content maintainers and lets us meet our use
> cases.
>
> We are planning to continue using the <fix> tag with a custom system
> attribute string to indicate that the <fix> tag contains BASH
> remediation content.  We are currently considering JSON notation as
> the leading candidate for writing the <fix> content because it is
> both easy to write and easy to parse.  The information we want to
> make sure we cover for running a remediation script is:
> Path to the script * Environment variables to define * Positional
>
> arguments to pass in to the script
>
> Using JSON notation in a <fix> tag, this would be the representation
> of that info:
>
> <fix system="urn:xccdf:fix:script:bash"> { "script" :
> "/usr/libexec/ssg/scripts/remediate_foo.sh" "environment-variables" :
> {"FOO" : "12", "TEST" : "<sub idref="xccdf_variable_foo" />"} 
> "positional-args" : ["test","<sub idref=" other_xccdf_variable" />"] 
> } </fix>
>
> The array of positional-args would be assumed to be ordered.  So this
> example would call: FOO=12 TEST=<value of xccdf_variable_foo>
> /bin/bash /usr/libexec/ssg/scripts/remediate_foo.sh test <value of
> other_xccdf_variable>
>
> We would appreciate any input & feedback regarding this approach.
>
> Thank you - Francisco Slavin
>
> _______________________________________________ scap-security-guide
> mailing list [e-mail] 
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

[Francisco Slavin]

Feedback in-line.  Unfortunately, I believe using unique XML markup under a <fix> tag invalidates the XCCDF document.
> -----Original Message-----
> From: [e-mail] [mailto:scap- 
> [e-mail]] On Behalf Of Jeffrey 
> Blank
>
> I think it might make more sense to do it in XML instead of JSON.
> Mixing JSON and XML makes one's eyes bleed in two different ways 
> instead of one way.  But I suppose it's parseable and transformable 
> either way.

Using XML occurred to me in order to be consistent with the rest of the document - I don't particularly like the mixed-up look, either.
Unfortunately, using XML in the document would render it invalid XCCDF.  According to the XCCDF schema, the <sub> tag is the only XML tag that can be a child to a <fix> element.  I tested out a simple JSON <fix> tag example to make sure it validated using xmllint.  I tried the same <fix> tag example using some invented XML tags which don't occur elsewhere in the XCCDF schema and the document would no longer validate.

I feel that keeping the XCCDF document valid according to schema is a significant constraint for our approach with this, which takes unique XML markup out of consideration.  If there's another way to do that I would be willing to consider it; I will readily admit I am not an XML expert.

Just to keep the SSG community posted, our approach for the next SecState release is to consume <fix> content with JSON markup.  Based on the use cases I described previously and the constraint of keeping the XCCDF valid it seems to be the cleanest approach to me.  We will certainly be open to shifting in the future if the community moves in a different direction or the schemas mature to the point where we can leverage SCAP-specific mechanisms to represent this information.  This JSON <fix> tag support is targeted for the version of SecState that will ship with CLIP for RHEL 6.2.
> Have you given though to making it look (a little bit) like what's in 
> the CRE spec for a cre_entry (pg 25)?
> http://csrc.nist.gov/publications/drafts/nistir-7831/Draft-NISTIR-
> 7831.pdf
>
> But perhaps in a more-convenient-for-human-editing format (something 
> for which automated transformation may be possible to CRE)?

We did want to make sure we picked a standard, easily-transformable means of representing this information when we landed on JSON.  We want to be able to support SCAP remediation specifications in the future as they mature.  From taking a quick look at the CPE schema it seems like we could easily boilerplate in RHEL 6.2 info for the <platform> information that the CPE spec will track as the remediation content being developed matures.

Thank you
 - Francisco Slavin

[Gary Gapinski]

Hello, Francisco:

On 09/28/2012 12:26 PM, Francisco Slavin wrote:
> Unfortunately, I believe using unique XML markup under a <fix> tag invalidates the XCCDF document.

It is invalid in an XCCDF document, but the security guide consists of
fragments of XCCDF which are not themselves XCCDF documents.

I have discussed this a bit in
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-September/....
> Using XML occurred to me in order to be consistent with the rest of the document - I don't particularly like the mixed-up look, either.
> Unfortunately, using XML in the document would render it invalid XCCDF.  According to the XCCDF schema, the <sub> tag is the only XML tag that can be a child to a <fix> element.  I tested out a simple JSON <fix> tag example to make sure it validated using xmllint.  I tried the same <fix> tag example using some invented XML tags which don't occur elsewhere in the XCCDF schema and the document would no longer validate.
>
> I feel that keeping the XCCDF document valid according to schema is a significant constraint for our approach with this, which takes unique XML markup out of consideration.  If there's another way to do that I would be willing to consider it; I will readily admit I am not an XML expert.

<fix> content must be rendered conformant during the assembly of the
ultimate XCCDF document(s). This is an unfortunate shortcoming, and
hopefully will be eventually remedied. As XCCDF currently stands, any
structure subordinate to <fix> must be something other than XML.

However, It does not have to be conformant  to XCCDF prior to assembly
into an XCCDF document.

As XML is the native "language" in which most of this content is cast,
my opinion is that we should strive to use XML generally. I have on past
occasion defined an XML syntax for a POSIX-like check expression
"language" (I think Peter Vrabec has as well) as well as one for <fix>.
Such syntaxes can rather easily be transformed from XML to JSON or other
suitable syntax; the reverse is not true, nor is an additional non-XML
syntax a benefit to schema-driven editing of XML.
> Just to keep the SSG community posted, our approach for the next SecState release is to consume <fix> content with JSON markup.  Based on the use cases I described previously and the constraint of keeping the XCCDF valid it seems to be the cleanest approach to me.  We will certainly be open to shifting in the future if the community moves in a different direction or the schemas mature to the point where we can leverage SCAP-specific mechanisms to represent this information.  This JSON <fix> tag support is targeted for the version of SecState that will ship with CLIP for RHEL 6.2.

I am not opposed to JSON in <fix> text for ultimate evaluation until
XCCDF has a more robust, multi-target-language syntax for what is often
referred to as "remediation". I do think that a general XML-based syntax
from which a JSON representation of an imperative language could be
derived would be the best form in which XCCDF fragments could be cast.

Just as an example, using your original example

<fix system="urn:xccdf:fix:script:bash">
{
    "script" : "/usr/libexec/ssg/scripts/remediate_foo.sh"
    "environment-variables" : {"FOO" : "12", "TEST" : "<sub
idref="xccdf_variable_foo" />"}
    "positional-args" : ["test","<sub idref=" other_xccdf_variable" />"]
}
</fix>

can also be represented as

<fix system="urn:xccdf:fix:script:bash">
    <execute xmlns="bash">
        <env>FOO=12</env>
        <env>TEST=<sub idref="xccdf_variable_foo"/></env>
        <command>/usr/libexec/ssg/scripts/remediate_foo.sh <sub
idref="other_xccdf_variable"/></command>
    </execute>
</fix>

or some other suitable variation. They're both rather cumbersome; using
only XML is singularly rather than doubly cumbersome. Multi-line scripts
are easier to embed in XML (rather than as a document presumed separate
from the XML document)

Essentially, JSON will cause some problems with schema-driven editing as
well as XML formatting and indentation. It is not easily transformed
using XSLT, whereas some manner of XML syntax can easily be transformed
into JSON.

Regards,

Gary