[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