oscap xccdf generate guide --profile allrules output/rhel6-xccdf.xml > output/rhel6-guide.html WARNING: Processing an unresolved XCCDF document. This may have unexpected results.
xmlwf input/checks/*.xml transforms/combinechecks.py input/checks > output/rhel6-oval.xml Duplicate ID, which will not be added: var_removable_partition Duplicate ID, which will not be added: var_removable_partition Duplicate ID, which will not be added: var_ssh_config_directory Duplicate ID, which will not be added: state_uid_root Duplicate ID, which will not be added: object_etc_skel_files Duplicate ID, which will not be added: var_samba_private_directory
joe
Great questions.
On 05/23/2012 04:34 PM, Joe Nall wrote:
oscap xccdf generate guide --profile allrules output/rhel6-xccdf.xml > output/rhel6-guide.html WARNING: Processing an unresolved XCCDF document. This may have unexpected results.
This is because the XCCDF document being provided is not "Resolved" as described in section 3.3 of the XCCDF spec at http://csrc.nist.gov/publications/nistir/ir7275r3/NISTIR-7275r3.pdf
(Short version: it has uses of the "extends" attribute, which we use for some Profiles. "Resolving" means that these are expanded.)
This non-resolving isn't causing any problems for us for guide generation. But we could resolve it -- and oscap can do it for us: oscap xccdf resolve --output rhel6-xresolv.xml rhel6-xccdf.xml ocap xccdf generate guide --profile allrules rhel6-xresolv.xml > rhel6-guide.html
(note that we need --output, not -o, for the resolve step; the oscap man page does not agree with the binaries in openscap-0.8.0-2 package.)
I'll shortly add a "resolve" step to the XCCDF prior to the guide Makerule (and ensure there are no undesirable side effects). (In fact this may simplify some of the transforms that are manually expanding "extends".)
xmlwf input/checks/*.xml transforms/combinechecks.py input/checks > output/rhel6-oval.xml Duplicate ID, which will not be added: var_removable_partition Duplicate ID, which will not be added: var_removable_partition Duplicate ID, which will not be added: var_ssh_config_directory Duplicate ID, which will not be added: state_uid_root Duplicate ID, which will not be added: object_etc_skel_files Duplicate ID, which will not be added: var_samba_private_directory
This is by design: it's artifact/evidence of our modular development of OVAL definitions (and their re-integration). This is because we have some identical OVAL objects/var/states in individual OVAL tests, and they are noted as duplicates when the combining occurs. So, this list should match what you expect (with regard to duplicate or shared vars/objs/states between individual definitions).
What I do not entirely understand is the extent to which an OVAL interpreter will re-use objects/states/vars with the same name, across evaluation of a set of definitions. This could be efficient, as a means of effectively "caching" results. I do not fully understand sections 5.3.1 and 5.3.2 in the OVAL spec document at http://oval.mitre.org/language/version5.10.1/OVAL_Language_Specification_01-...
...nor do I know where the answer to this question would be documented. But I bet some people on the list do.
When dealing with this duplication issue, I had also wanted to compare XML fragments with duplicate IDs to try to guarantee syntactic equality, but there was no trivial way to do this in lxml.etree. So currently we rely on developers to ensure congruence among object/var/state with the same ID. The first object/var/state is the one actually added.
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Joe Nall