support for alternate titles

Gary Gapinski Gapinski at nasa.gov
Wed Sep 26 08:34:09 UTC 2012


On 09/04/2012 01:55 PM, Gary Gapinski wrote:
> I would like at some later time to discuss a syntax for benchmark
> fragments, an XML Schema or other suitable schema for such, inclusive of
> such issues like variant titles. This would foster more rigor of
> maintenance of individual fragments.

I started looking at this with an eye to using NVDL and have some 
initial observations and questions.

I chose RHEL6/input/system/accounts/session.xml as a representative 
example fragment (there's probably a better term than "fragment" for 
such things, but I don't have one). It contains XCCDF <Group>s, 
<Value>s, <Rule>s, proto-OCIL, OVAL references, and other stuff.

I would hope that OVAL checks could eventually reside in the same 
document in which they are currently cited: namely, within the fragment 
containing the referencing XCCDF.

It appears that the project is currently targeting SCAP version 1.1 
(based on the chosen namespace declaration for XCCDF output), thus the 
schema versions are XCCDF 1.1.4, OVAL 5.8, OCIL 2.0, CPE 2.2, and CCE 5. 
Eventual adoption of SCAP version 1.2 would change this to XCCDF 1.2, 
OVAL 5.10, and CPE 2.3.

Would both SCAP versions be simultaneously supported at some later time? 
(at the fragment level - obviously, the transformations that assemble 
the fragments must choose a single SCAP version for their result, and 
that in turn could be derived from the highest SCAP version level found 
in the fragments chosen for assembly). Seems like that would be the 
case. OVAL's lack of namespace precision for different versions makes 
this a bit more complicated in an NVDL environment, but handling that 
(multiple OVAL versions with identical namespaces) can be discussed at a 
later time.

Right off the bat, more explicit namespacing will be required. Things 
are currently relative and depend on the eventual transformation to 
assign namespace context. This means that fragments such as XCCDF, OVAL, 
and OCIL would need an explicit namespace declaration (not on every 
element, but at least at the top-level enclosing element) using XML 
prefixes or xmlns attributes, ditto embedded XHTML, and another 
namespace (one vaguely like 
http://fedorahosted.org/scap-security-guide/fragment/1.0) will be needed 
for other stuff like variant titles or anything else that is useful but 
not strictly XCCDF, OVAL, or OCIL. This other "stuff" is currently 
precursors such as <ocil>, <oval>, <ref>, etc., essentially anything 
that is not defined strictly as (in) XCCDF, OVAL, or OCIL. This other 
stuff will need a schema: i.e., a schema is needed for the structure of 
a fragment.

If things are explicitly relegated to their respective namespaces, then 
an NVDL description of a fragment seems achievable. This would allow the 
subordinate schemata such as XCCDF to be directly applied during 
schema-driven editing. An additional one or more schemata would be 
needed to describe the fragment itself.

NVDL is by no means essential, just handy. It is certainly possible to 
define a novel schema for a fragment that ensures reasonable quality of 
the portions that ultimately become XCCDF, OVAL, etc., since those 
schemata do not undergo frequent change, and a schema for a fragment is 
a necessary item in any case. This is particularly true if the 
components of a fragment are represented using more tractable syntaxes 
than OCIL and OVAL, such as is currently the case with the proto-OCIL 
and -OVAL syntaxes.

In other words, if one chooses to wear the various SCAP hair shirts for 
authoring, NVDL provides a way to apply the associated schemata while 
editing. No hair shirts, no need for NVDL.

Things such as alternate titles require more effort. For example, it's 
quite easy to say that a fragment can contain an XCCDF <Rule>, and have 
that <Rule> processed according to the XCCDF schema, and easy to say 
that the fragment can specify variant <title>s separately from the XCCDF 
<Rule> (one of the variants can be presumed to be selected in a 
transformation assembly), but it is _not_ so easy to ensure that a 
variant <title> can be interpreted in the context of the XCCDF in which 
it would ultimately reside - while editing the fragment using a 
schema-driven editor.

Less easy than that is ensuring the proper edit-time interpretation of 
an XCCDF <sub> in an XHTML portion of some XCCDF prose element which is 
cited as a variant value for the prose element. I would hope that such 
variations are eschewed, if only because they would occur outside the 
context in which they would otherwise afford the application of the 
normative schema for that context via NVDL.

In any case, if more rigor is to be obtained for fragment maintenance, 
which is somewhat the same as saying schema-driven editing is desirable, 
a bit of effort at some later convenient time would be required to 
transform the existing fragments into a better-defined and -normed 
syntax. If there is some accord on the desirability of this, I'd be 
happy to create the necessary examples, transform(s), and schemata.


More information about the scap-security-guide mailing list