How do I track these warnings down?

Jeffrey Blank blank at eclipse.ncsc.mil
Thu May 24 16:04:42 UTC 2012


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-20-2012.pdf

...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.


More information about the scap-security-guide mailing list