On 8/26/14, 6:05 AM, Jan Lieskovsky wrote:
Hello folks,
within effort to rewrite umask checks (more about the motivation for this
later within its dedicated email thread) encountered the following
RHEL/6/transforms/cpe_generate.py script related issue.
Use case: Let's consider RHEL/6/input/checks/accounts_umask_etc_profile.xml
OVAL check would have the form as attached (it's not the final form of the
check. The final one will be slightly more complex yet. In any case the attached
form is syntactically correct one & sufficient to demonstrate the issue I would
like to speak below about), then running 'make' in scap-security-guide/RHEL/6
subdirectory returns the following error when trying to generate the datastream
output:
oscap ds sds-compose output/ssg-rhel6-xccdf-1.2.xml output/ssg-rhel6-ds.xml
oscap ds sds-add output/ssg-rhel6-cpe-dictionary.xml output/ssg-rhel6-ds.xml
File 'output/ssg-rhel6-ds.xml' line 32236: Element
'{http://oval.mitre.org/XMLSchema/oval-definitions-5}object_component': No match
found for key-sequence ['oval:ssg:obj:111'] of keyref
'{http://oval.mitre.org/XMLSchema/oval-definitions-5}objectKeyRef'.
Invalid SCAP Source Datastream content(1.2) in output/ssg-rhel6-ds.xml.
make: *** [content] Error 1
Tried to replicate this to no avail... building on RHEL 6:
xsltproc /usr/share/openscap/xsl/xccdf_1.1_remove_dangling_sub.xsl
output/ssg-rhel6-xccdf.xml \
> output/ssg-rhel6-xccdf-nodangles.xml
xsltproc --stringparam reverse_DNS org.ssgproject.content
/usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \
output/ssg-rhel6-xccdf-nodangles.xml >
output/ssg-rhel6-xccdf-1.2.xml
sed -i '/idref="dangling reference to /d' output/ssg-rhel6-xccdf-1.2.xml
oscap ds sds-compose output/ssg-rhel6-xccdf-1.2.xml
output/ssg-rhel6-ds.xml
oscap ds sds-add output/ssg-rhel6-cpe-dictionary.xml
output/ssg-rhel6-ds.xml
oscap ds sds-add output/ssg-rhel6-oval.xml output/ssg-rhel6-ds.xml
Investigated the problem further, and noticed the problem is content of
RHEL/6/output/ssg-rhel6-cpe-oval.xml
file. Namely it contains the content as follows:
...
</states><variables><local_variable id="oval:ssg:var:110"
datatype="int" comment="x" version="1">
<substring substring_start="1" substring_length="1">
<object_component item_field="subexpression"
object_ref="oval:ssg:obj:111"/>
</substring>
</local_variable>
</variables></oval_definitions>
which after more detailed look explains why 'oval:ssg:obj:111' wouldn't be
defined in output/ssg-rhel6-ds.xml
file (the oval:ssg:var:110 local variable references oval:ssg:obj:111, but this object
isn't defined
within that ssg-rhel6-cpe-oval.xml file [only in different part of ssg-rhel6-ds.xml
file]).
So investigated further to see, which part of the RHEL/6's Makefile generates /
includes this variable,
when creating ssg-rhel6-cpe-oval.xml file, and noticed the responsible script being
RHEL/6/transforms/cpe_generate.py.
The questions:
1) Can someone more familiar with the implementation of this script clarify it's
purpose?
It requires two input files (OVAL file & CPE file), and one identifier (ssg), and
generates
'ssg-rhel6-cpe-oval.xml' file.
2) Can someone more familiar with the implementation of this script clarify the need for
the
following construct within it?:
82 variables = ovaltree.find("./{%s}variables" % oval_ns)
83 cpe_variables = extract_referred_nodes(ovaltree, variables,
"var_ref")
84 if cpe_variables:
85 variables.clear()
86 [variables.append(cpe_variable) for cpe_variable in
cpe_variables]
87 else:
88 ovaltree.remove(variables)
Is it there to (when generating ssg.ini object name to object id file) to
incorporate
also OVAL local_variables that might reference another variables via the
"var_ref"
attribute?
The reason why I am asking being that have noticed, when I comment out the following
part
of this file (IOW when the cpe_generate.py script has the following form around the
critical lines):
82 variables = ovaltree.find("./{%s}variables" % oval_ns)
83 #cpe_variables = extract_referred_nodes(ovaltree, variables,
"var_ref")
84 #if cpe_variables:
85 # variables.clear()
86 # [variables.append(cpe_variable) for cpe_variable in
cpe_variables]
87 #else:
88 ovaltree.remove(variables)
the aforementioned error message:
File 'output/ssg-rhel6-ds.xml' line 32236: Element
'{http://oval.mitre.org/XMLSchema/oval-definitions-5}object_component': No match
found for key-sequence ['oval:ssg:obj:111'] of keyref
'{http://oval.mitre.org/XMLSchema/oval-definitions-5}objectKeyRef'.
when generating ssg-rhel6-ds.xml isn't reported anymore & the content builds
successfully.
Since I wouldn't like to break something, the purpose of this email is to ask someone
more familiar
with the implementation of cpe_generate.py script, why the cpe_variables section (lines
from #83 up
to #87 need to be present there)?
Is there a chance this behaviour is somehow related with the following commit:
[1]
https://github.com/OpenSCAP/scap-security-guide/commit/59d650ffe140e4ae74...
?
For example in the sense the original meaning of 'cpe_variables' part of
cpe_generate.py was to include
also variables, that reference other variables via 'var_ref' attribute into final
ssg.ini file
(and assign IDs in the form of "oval:ssg:var:..." to them too)? But the change
[1] is causing
variable objects having 'var_ref' attribute is now included within relabelids.py
script & therefore
the 'cpe_variables' section of the cpe_generate.py script is not needed anymore
& can be safely remove
as suggested above (or in the also attached RHEL_6_transforms_cpe_generate_py.diff
patch)?
Any hints you can provide wrt to observed cpe_generate.py behaviour & how to possibly
fix it
are appreciated.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: If wondering why this problem didn't show earlier, assuming there isn't
such construct
(local_variable referencing another local_variable referencing
textfilecontent54_object)
used in the current content yet. Tried also different approach (encapsulate those
local_variables
into variable_objects & reference those objects instead), but it didn't
help (in the sense
datastream output would be successfully generated).
--
Shawn Wells
Director, Innovation Programs
shawn(a)redhat.com | 443.534.0130
@shawndwells