Yes -- please push as a bugfix.
The utils/verify-references.py script (which must be invoked from the
output directory using "../utils/verify-references.py" ) has the logic
to detect these kinds of things. Perhaps we should add it to the
make-validate Makerule to catch these kinds of (non-obvious) oopses...
On 04/21/2013 11:35 PM, Shawn Wells wrote:
On 4/21/13 10:39 PM, Jeffrey Blank wrote:
> Rule selection specified by a Profile overrides selection specified in
> the Rule itself.
> Any Rules which are not explicitly marked as "selected=false" will be
> evaluated.
>
> Thus, our convention is to mark all Rules as "selected=false" in the
> actual Rule attribute, because we wish to have Profile-driven
> evaluation. (And all of our Profiles only ever feature "selected=true".)
>
> Please see page 20 of
>
http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf
>
> Note there that the default is "true" for selection in a Rule. So, if
> we weren't intentionally de-selecting each Rule using its attribute
> (selected=false), even in a Profile-driven evaluation (which did not
> include the Rule!) it would default to true and be evaluated. Yes,
> this would be quite unexpected. This is explained by the fact that
> the earlier versions of XCCDF has no Profiles. The thought (at that
> time, from what I can infer) is that end-users would receive a body of
> XCCDF and then select/de-select (using tooling) what they wanted (and
> save the resulting XCCDF content as their own).
>
> But that is not the way it turned out. The way it turned out was that
> widespread authoring/modification of XCCDF never really occurred, and
> instead XCCDF really only took hold as a means of expressing a small
> number of government security baselines (all of which were expressed
> as Profiles, rarely modified, due to the inadequacy or lack of
> adoption of any tooling for authoring).
>
> So I hardly blame you for being confused. The decision tree for XCCDF
> evaluation is vastly more complicated than needed for any use case
> I've ever seen (or could practically imagine).
Jeff pinged me offline and it turns out this was caused by the id tag
within the OVAL not matching the filename. I threw together a patch here:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-April/0...
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide