Thank you for your reply, Shawn.
----- Original Message -----
> From: "Shawn Wells" <sh...@redhat.com>
> To: scap-security-guide@lists.fedorahosted.org
> Sent: Tuesday, August 26, 2014 8:01:26 PM
> Subject: Re: On the purpose of cpe_generate.py script (& mainly cpe_variables
> section within it)
>
> 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
Right, the observed behaviour isn't problem of existing RHEL-6 content. But it
appears when you replace the existing
RHEL/6/input/checks/accounts_umask_etc_profile.xml
with the previously attached one (should mention this immediately in my
original post) &
try to build the content (IOW perform 'make' in RHEL/6 directory).
To describe the motivation for the umask OVAL checks rewrite in more detailed
way -
the reason being right now we claim PASS / SUCCESS only in case specified umask
exactly
matches the requirements. But we should PASS / SUCCESS also in case, the umask
is set
up in more strict way (IOW consider the requirement to be 002, the 022 one
should PASS
the requirement too).
To be able to do this, we can't compare umask just as strings (since e.g. 100
is greater
than 002, but "weaker"). Therefore we need to convert the retrieved string into
numbers
then those numbers into the corresponding bit representation & perform bitwise
AND operation
on them (that's why all those variables are needed).
Thank you in advance for any further guidance.
Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
>
>
>
>
> 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/59d650ffe140e4ae742dc7b4893df278bf1b3334
> ?
>
> 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 sh...@redhat.com | 443.534.0130
> @shawndwells
>
> --
> SCAP Security Guide mailing list
> scap-security-guide@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/
--
SCAP Security Guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/
