[Xccdf-dev] Requirement SCAP.V.600.1 might pose undefined behavior (?)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

[Xccdf-dev] Requirement SCAP.V.600.1 might pose undefined behavior (?)

Simon Lukasik
Hello SCAP people,

We have been going through SCAP product validation requirements
(NISTIR-7511r3) and we have found one requirement which we would like to
raise awareness about.

    SCAP.V.600.1: The vendor SHALL provide documentation and
    instruction on how to select a specific XCCDF benchmark (by ID)
    when processing an SCAP data stream or data stream collection.

I understand the rationale behind this requirement. And I see that it
might indeed be convenient for users to pick a checklist from DataStream
collection by ID.

Nevertheless, I am concerned about this requirement as it is kind of
surprising. This requirement effectively eliminates some of the
DataStream features. And it seems to go against the DataStream
philosophy. Thus it seems to posse more problems than it solves.

Even though we are able to amend our product (OpenSCAP) to allow
selection by Benchmark/@id, we still prefer selection by
component-ref/@id. The selection by component-ref/@id allows for greater
range of functionalities. I will try to explain my thinking in greater

A DataStream file consists basically of two parts:

    (1) a list of <data-stream>-s
    (2) a list of <component>-s

A data-stream (1) contains component-ref elements often supplied with
the <catalog> element. The catalog defines mapping between multiple
components. There might be multiple parallel mappings between existing
components -- each of them is represented by single component-ref. This
is crucial, there might be multiple different mappings for the very same

A single component (think of our XCCDF Benchmark) can be part of
multiple component-ref. Thus the selection of component-ref is superior
to the selection of Benchmarks.

As an example, consider a DataStream file which includes:

 (1) One XCCDF Benchmark file, applicable to all platforms.
     That is component 1.
 (2) Two OVAL files, one for Windows another for Linux platform.
     That are components 2 and 3.
 (3) Two component-ref elements which both refer to the XCCDF.
     But each defines its own different catalog. The first catalog
     refers the linux-oval.xml while the second catalog refers to

I am herewith submitting such (quickly crafted) DataStream file under
the attachment for your perusal.

If a SCAP product (be it OpenSCAP or other) is forced to select the
Benchmark by ID, it cannot decide which mapping (<catalog>) should be
used. Behavior here seems to be undefined and different products might
behave differently in this case.

In OpenSCAP, we think about using the following algorithm:

 - Search in list of component-refs for component-ref with a given ID
    - if found use the given matching component-ref and its catalog
 - Otherwise, search for a component with matching Benchmark/@id
    - since there might be multiple such components use the first
 - Search for component-ref using given component
    - since there might be multiple such, use the first one

That way, OpenSCAP can meet the requirement, while having the default
behavior more predictable and better defined.

We will be grateful for any input on our thinking!

In case you are interested in playing with the attached example. You can
use the following OpenSCAP commands.

(1) This uses the first oval component and thus pass:

 $ oscap xccdf eval \
      --xccdf-id scap_org.open-scap_cref_first-xccdf.xml \

(2) while this command will use the second oval resulting in fail:

 $ oscap xccdf eval \
     --xccdf-id scap_org.open-scap_cref_second-xccdf.xml \

The behavior would be undefined, when using Benchmark (ID) as suggested
by (SCAP.V.600.1).

Best regards,

Simon Lukasik
Security Technologies
Red Hat, Inc.
My SCAP blog: http://isimluk.livejournal.com

XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

sds-complex.xml (7K) Download Attachment