[PATCH 0/4] support for alternate titles

Gary Gapinski Gapinski at nasa.gov
Wed Sep 5 09:06:53 UTC 2012


On 09/04/2012 05:34 PM, Jeffrey Blank wrote:
>> It is highly likely that any DISA FSO titleing will not be appropriate
>> for all other venues.
> Right.  And while it would be ideal and efficient for everyone to be
> flexible and reach a consensus on language, if someone has special
> needs, we can try to accomodate.
>
> I strongly encourage discussion on this matter as we find our way forward.
>
>> Thus, the <title> for a <Rule> (and likely <Group>s and <Profile>s,
>> possible <Value>s) becomes a 1-n attribute of such, and each instance
>> will need a domain-specific (e.g., DISA FSO) unique identifier that may
>> apply to things other than titles (<Rule> ids, descriptions, warnings,
>> rationales, etc).
> Well, let's approach this very carefully, for a few different reasons.
> The Rule id is the one thing that we are planning to use as an
> (upstream) anchor.  Issuers of the content (that leverage it) could use
> <note>s in their derivations to ensure a stable and maintainable mapping
> if they need to alter this.  Creating alternate, additional
> descriptions, warnings, and rationales could at some point turn into
> hosting a complete fork of ourself, which would significantly increase
> maintenance and support costs.

Yes, it (variants) will.

Variant <title>s are the camel's nose under the tent. The remainder of 
the camel would likely consist of <title>-like elements, such as all 
other prose elements.

I am unfortunately quite cynical, but it certainly seems after many 
years of watching this SCAP stuff evolve, that no sooner than some 
simple vehicle is proposed, there is a marked propensity to start 
warping it by adding fuzzy dice, oversize tires, underlighting, painting 
flames on the sides, attaching a raccoon tail to the antenna, and 
plastering the rear window and bumper with all sorts of decals and 
stickers including one that reads "If You Can Read This, Please Flip Me 
Back Over".

The fact that DISA FSO needs variant titles indicates that, despite 
years of adornments, the SCAP formats are not yet adequate for routine 
general use. The request is of course also quite self-serving.

Variant <title>s can be accommodated for now, simply. I think they are 
uniquely identified by the triple (<Rule>, DISA FSO, RHEL6), where the 
latter is assumed, unfortunately without explication.

As for element ids… things are not simple.

NIST IR 7275 rev 4 
<http://csrc.nist.gov/publications/nistir/ir7275-rev4/nistir-7275r4_updated-march-2012_clean.pdf> 
§6.2.3 makes the audacious assertion that all ids are "globally unique" 
(and must additionally labor under a rather idiosyncratic syntax). 
Previously, ids were unique within a benchmark document, and in fact are 
merely that as regarded from a pure XML prospect. I suspect the globally 
unique steamship will eventually founder on the rocks of practicality, 
but let's assume for now that identifiers can be coined and will have at 
least the properties of being unique to scap-security-guide as well as 
having moderate persistence, which suffices for scap-security-guide 
purposes.

Hopefully, those chosen will fulfill any unstated requirements of DISA 
FSO, which at least for <title>, indicate a desire to control at least 
prose attributes of <Rule>s (and here I'm using attribute in the 
abstract sense, not as an attribute of an XML element).

Having (rather) immutable ids is useful, though <ident> currently 
provides much latitude to associate <Rule>s with other things. 
Maintaining what are essentially <Rule>s as individual documents 
provides handy compartmentalization. These separate documents can be 
combined with others to form <Benchmark> documents which then are 
expected to have tidy identifiers for all other major XCCDF elements. 
This is quite messy (because of IR 7275), and I have not seen any intent 
thus far to do anything other than provide these in some suitable 
fashion as <Benchmark>s are assembled. I would not expect to do anything 
more, nor see anything to be gained by doing more.

It appears to me that the individual documents from which security 
guides can be assembled are in and of themselves unique identifiers, 
that one could (but need not since the containing document has a unique 
"URI") choose an NCName for each that is peculiar to scap-security-guide 
(i.e., is unique within the scap-security-guide domain) and use it in 
the «id» attribute of the <Rule> element, use only one id, that any 
arbitrary compilation/derivation might or might not preserve these 
chosen ids in any final assemblage, and that sufficient means exist to 
denote provenance in these assemblages without necessarily forcing 
scap-security-guide <Rule> ids to be anything in particular or having 
canonicality {1,1}.

For <Benchmark>, <Profile>, and <Group> element identifiers, the sky is 
the limit. I presume <Value> identifiers will of necessity track <Rule> 
identifiers.

In my opinion, <Rule>s and their identifiers should endure minor and 
major updates to RHEL without requiring change. They should be 
applicable to RHEL-equivalent distributions, and ideally applicable to 
other distributions when the <Rule> is catholic enough to be generally 
applicable (e.g., display an SSH banner).

I won't even mention OVAL identifiers.





More information about the scap-security-guide mailing list