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/003061.html
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Reply via email to