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. _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
