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). On Fri, Apr 19, 2013 at 5:58 PM, Shawn Wells <[email protected]> wrote: > I've been going through the OVAL code and have stumped myself. The > partition_for_* rules are enabled in the XCCDF profiles, yet somehow is > marked as selected=false in the final output: > > $ grep -rin partition_for_tmp input/profiles/ > input/profiles/usgcb-rhel6-**server.xml:5:<select > idref="partition_for_tmp" selected="true" /> > input/profiles/common.xml:4:<**select idref="partition_for_tmp" > selected="true"/> > > $ grep -rin partition_for_tmp output/ssg-rhel6-xccdf.xml > 43: <select idref="partition_for_tmp" selected="true"/> > 259: <select idref="partition_for_tmp" selected="true"/> > 500: <select idref="partition_for_tmp" selected="true"/> > 720: <select idref="partition_for_tmp" selected="true"/> > 946: <select idref="partition_for_tmp" selected="true"/> > 1400: <Rule id="partition_for_tmp" selected="false" severity="low"> > > In the ssg-rhel6-xccdf.xml file, the OVAL points to oval:ssg:2741: > <check-content-ref name="oval:ssg:def:2741" href="ssg-rhel6-oval.xml"/> > > And when I check for that in ssg-rhel6-oval.xml, it doesn't exist: > $ grep -in oval:ssg:2741 output/ssg-rhel6-oval.xml > (no return) > > When I load up ssg-rhel6-oval.xml and look for the rule, it's actually > oval:ssg:def:841: > <definition class="compliance" id="oval:ssg:def:841" version="1"> > <metadata> > <title>Ensure /tmp Located On Separate Partition</title> > > I started to play with relabelids.py and only made things worse. > Jeff/Dave, any chance you could take a look at this? > > ______________________________**_________________ > scap-security-guide mailing list > scap-security-guide@lists.**fedorahosted.org<[email protected]> > https://lists.fedorahosted.**org/mailman/listinfo/scap-**security-guide<https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide> >
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
