SSG Audit + Aqueduct Remediation Linking

Gary Gapinski gapinski at nasa.gov
Fri Sep 28 18:08:59 UTC 2012


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/001686.html.

> 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



More information about the scap-security-guide mailing list