On 02/20/2013 07:01 PM, Jeffrey Blank wrote:
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.
I think this will be icky if XCCDF <Value>s are considered useful. There
is too little coordination in XCCDF for <Value>s and where they might be
used. XCCDF <Value>s were not well thought out for use in more than just
benchmark "tailoring".
It may be long-term necessary to consider alternatives.
Shorter-term, the assembly process starting from (the woefully
namespace-less, which I think I can correct) fragments can likely be
adapted to propagate variables of interest into SCAP-compliant XML. I
don't think <xccdf:sub> is the right way.
If it is now close to the time when a namespace (or two) for
scap-security-guide fragments, and a schema for those, can be
considered, I'd be willing to put up a trial balloon. This ultimately
becomes an exercise in avoiding arbitrary limitations of XCCDF by
allowing reasonable and useful expression ahead of (SP 800-126 rev 1)
XCCDF generation. As in variables that end up manifest in checks and
fixes. Ideally, the same meaning of value/variable (e.g., password
length) in all venues.
I don't think XCCDF should be levied on content authors, rather,
something useful that can be competently turned into XCCDF should be
provided. Accompanied by a schema. It can be better than XCCDF; the
shortcomings of such a transformation can be noted so that the
proto-XCCDF/OVAL content can be dumbed-down as and if necessary.