<div dir="ltr"><div class="gmail_default" style="font-size:small">+1 on work to support OVAL authoring.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Greg Elin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 3:17 AM, Jan Cerny <span dir="ltr">&lt;<a href="mailto:jcerny@redhat.com" target="_blank">jcerny@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<div><div class="h5"><br>
----- Original Message -----<br>
&gt; From: &quot;Jan Lieskovsky&quot; &lt;<a href="mailto:jlieskov@redhat.com">jlieskov@redhat.com</a>&gt;<br>
&gt; To: &quot;Jan Cerny&quot; &lt;<a href="mailto:jcerny@redhat.com">jcerny@redhat.com</a>&gt;<br>
&gt; Cc: &quot;SCAP Security Guide&quot; &lt;<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a>&gt;<br>
&gt; Sent: Friday, September 11, 2015 11:39:40 AM<br>
&gt; Subject: Re: A tool for support of SCAP content development<br>
&gt;<br>
&gt;<br>
&gt;  Hello Jan,<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; &gt; From: &quot;Jan Cerny&quot; &lt;<a href="mailto:jcerny@redhat.com">jcerny@redhat.com</a>&gt;<br>
&gt; &gt; To: &quot;SCAP Security Guide&quot; &lt;<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a>&gt;<br>
&gt; &gt; Sent: Thursday, June 4, 2015 9:15:42 AM<br>
&gt; &gt; Subject: A tool for support of SCAP content development<br>
&gt; &gt;<br>
&gt; &gt; Hello,<br>
&gt; &gt;<br>
&gt; &gt; Nowadays, there is almost no support for OVAL content development.<br>
&gt;<br>
&gt; Agree in this point.<br>
&gt;<br>
&gt; &gt; The developers have to edit the XML files manually, there is no<br>
&gt; &gt; analysis tool, no debugger or any other tool that could make<br>
&gt; &gt; the content development faster and easier.<br>
&gt; &gt; I have started working on a new utility that will be able to<br>
&gt; &gt; debug OVAL checks, show step-by-step how they are evaluated,<br>
&gt; &gt; browse collected objects and system characteristics, communicate<br>
&gt; &gt; with probes, etc.<br>
&gt;<br>
&gt; Two questions:<br>
&gt; * is this new tool intended to become part of the openscap-* package,<br>
&gt;   or rather the plan being it to be a separate tool?,<br>
<br>
</div></div>It was decided to be as part of the openscap.<br>
Official instructions approved by university says &quot;implement this in the OpenSCAP project<br>
by form of editing existing source code.&quot;<br>
For university instructions, see Description in Czech on this page:<br>
<a href="https://diplomky.redhat.com/topic/show/335/a-tool-for-development-of-oval-definitions-within-openscap-project" rel="noreferrer" target="_blank">https://diplomky.redhat.com/topic/show/335/a-tool-for-development-of-oval-definitions-within-openscap-project</a><br>
I should definitely put the link on the wiki.<br>
<span class=""><br>
&gt; * above you speak about debugger -- is the plan to add also profiler?<br>
<br>
</span>It is not in my plan now, but thank your very much for your idea!<br>
<div><div class="h5"><br>
&gt;<br>
&gt; &gt; I&#39;m working on design of the utility now. I&#39;m considering many<br>
&gt; &gt; alternatives, so I would like to ask you a few questions.<br>
&gt; &gt; * Can you describe most common problems that you have to face<br>
&gt; &gt;   when you create the OVAL content?<br>
&gt;<br>
&gt; Absence of ability to debug a particular OVAL check. Right now<br>
&gt; it&#39;s possible to use &#39;oscap oval eval / oscap oval collect&#39;<br>
&gt; for particular rule to determine what got actually collected on<br>
&gt; the system. This approach is working for simple rules. But it does<br>
&gt; not scale properly (if the underlying OVAL object consist of another<br>
&gt; OVAL variable, that variable using some OVAL functions on other<br>
&gt; variables and so on, it&#39;s hard to determine which OVAL object failed<br>
&gt; to be collected at the beginning -- which OVAL object is responsible<br>
&gt; for the whole rule failure).<br>
&gt;<br>
&gt; Next step is XCCDF evaluation - while the corresponding OVAL check might<br>
&gt; work properly, it&#39;s possible (due to combination of &quot;check&quot;,<br>
&gt; &quot;check_existence&quot;,<br>
&gt; &quot;entity_check&quot; attributes, order and / or logical operations between the<br>
&gt; different OVAL criterions) the final XCCDF rules is still failing even<br>
&gt; in the case &quot;some&quot; OVAL objects have been collected on the system.<br>
&gt;<br>
&gt; Right now oscap provides &#39;oscap xccdf eval .. --oval-results&#39; combination<br>
&gt; alllowing to inspect, why the rule as a whole did not pass (e.g. wrong<br>
&gt; &quot;check&quot; / &quot;check_existence&quot; attributes etc.).<br>
&gt;<br>
&gt; But it would be good if the new tool would support XCCDF debugging too<br>
&gt; (something like &#39;oscap xccdf eval ... --oval-results&#39; is allowing now,<br>
&gt; but enhanced).<br>
<br>
</div></div>I am working now on enhancing the debug infos and introduce &quot;--verbose&quot; option<br>
in oscap tool. I think it is a good first step.<br>
<div><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt; &gt; * How do you usually solve these problems?<br>
&gt;<br>
&gt; See above. By separating the rule intended to be debugged. Then running:<br>
&gt; * oscap oval eval --id<br>
&gt; * oscap oval collect --id<br>
&gt; * oscap xccdf eval .. --oval-results<br>
&gt;<br>
&gt; combination of commands (depending on the level [e.g. if OVAL itself,<br>
&gt; or at XCCDF level] the OVAL check is failing).<br>
&gt;<br>
&gt; &gt; * Can you tell me an example when did you run into issues with OVAL?<br>
&gt;<br>
&gt; Basically any a bit more complex OVAL check needs to be designed in<br>
&gt; stages (from top to bottom). Consider OVAL criterion requiring presence<br>
&gt; just some OVAL object, this object to consist of multiple stages, e.g.:<br>
&gt;<br>
&gt; * you first collect something on the system into object, save the<br>
&gt;   subexpression of it into &lt;local_variable&gt;,<br>
&gt; * apply couple of functions to that variable, finally create new final<br>
&gt;   object from the last variable. This final object is then used in the<br>
&gt;   OVAL test.<br>
&gt;<br>
&gt; Right now it needs to be done from bottom to the top (at each level, at<br>
&gt; each &lt;local_variable&gt; you mostly need to verify it returns appropriate<br>
&gt; results). Other issue is OVAL standard reporting functionality. AFAICT<br>
&gt; the standard requires the rule to return &#39;error&#39; also in the case the<br>
&gt; particular OVAL rule wasn&#39;t able to obtain child results (results for<br>
&gt; the child objects compositing the final object). Having seen this &#39;error&#39;<br>
&gt; result for the first time, it&#39;s not clear if:<br>
&gt; * OVAL check truly has a syntax error,<br>
&gt; * or OVAL check is correct, but the engine wasn&#39;t able to determine value<br>
&gt;   for some of the OVAL variables above in the evaluation tree.<br>
&gt;<br>
&gt; Another issue / RFE in &#39;oscap oval eval / collect&#39; functionality is the<br>
&gt; &#39;--id&#39; parameter. IIRC as of right now it supports specification of<br>
&gt; an ID just for OVAL objects (therefore having OVAL variable manipulating<br>
&gt; some previously collected OVAL object via some OVAL function, it&#39;s<br>
&gt; impossible to see the retrieved values of that variable directly.<br>
&gt;<br>
&gt; You need to see the values of the original OVAL object, then create<br>
&gt; another OVAL object from that OVAL variable using the OVAL function,<br>
&gt; to be able to see the true values, that OVAL variable is holding).<br>
&gt;<br>
&gt; Not to speak to abstract. Consider the following:<br>
&gt;<br>
&gt; &lt;ind:textfilecontent54_object id=&quot;my_object&quot; ..&gt;<br>
&gt;   &lt;ind:filepath&gt;..&lt;/ind:filepath&gt;<br>
&gt;   &lt;ind:pattern ..&gt;..&lt;/ind:pattern&gt;<br>
&gt;   &lt;ind:instance ..&gt;..&lt;/ind:instance&gt;<br>
&gt; &lt;/ind:textfilecontent54_object&gt;<br>
&gt;<br>
&gt; &lt;local_variable id=&quot;my_variable&gt;<br>
&gt;   &lt;some_oval_function_here, e.g. &quot;split&quot;, &quot;concat&quot;, whatever&gt;<br>
&gt;     &lt;object_component object_ref=&quot;my_object&quot; /&gt;<br>
&gt;     ..<br>
&gt;   &lt;/some_oval_function_here&gt;<br>
&gt; &lt;/local_variable&gt;<br>
&gt;<br>
&gt; Right now it&#39;s not possible to perform the following:<br>
&gt;<br>
&gt;   oscap oval collect --id &quot;my_variable&quot; --syschar /tmp/out<br>
&gt;<br>
&gt; because &quot;my_variable&quot; doesn&#39;t constitute an OVAL object (therefore<br>
&gt; to bypass it, it&#39;s necessary to define new artificial OVAL object<br>
&gt; from that &quot;my_variable&quot; local variable, and try to collect it).<br>
&gt;<br>
&gt; Therefore it would be very handy if &#39;collect&#39; could be enhanced<br>
&gt; to support variables too.<br>
<br>
</div></div>This is a nice use-case.<br>
<span class=""><br>
&gt;<br>
&gt; &gt; * Imagine an ideal tool for an OVAL developer. What should it be<br>
&gt; &gt;   able to do? What would be its features?<br>
&gt;<br>
&gt; Maybe above being a sketch. From the above it&#39;s not clear if the<br>
&gt; new tool should be just debugger, or profiler too. If the debugger,<br>
&gt; basically it would be able to:<br>
&gt; * report values of particular OVAL objects, variables at any time<br>
&gt;   of OVAL evaluation,<br>
&gt; * report the branch OVAL check has been evaluated (like OVAL check<br>
&gt;   went through criterion #1, the rest of the criteria weren&#39;t taken<br>
&gt;   into account, since criterion #1 already succeeded),<br>
<br>
</span>I am going to achieve this by collecting all the possible information<br>
during evaluating the content and processing those information to have<br>
a meaningful output.<br>
<span class=""><br>
&gt; * + the requests as formulated above.<br>
<br>
&gt;<br>
&gt; If we would talk also about profiling capabilities - it would be<br>
&gt; able to report things like CPU usage in %, virtual memory usage,<br>
&gt; and or count of system files processed when evaluating particular rule.<br>
<br>
</span>I would consider this, it can be useful feature to avoid bugs with<br>
excessive memory consumption caused by badly written content.<br>
<span class=""><br>
&gt;<br>
&gt; This would be handy to optimize current form in many rules.<br>
&gt;<br>
&gt; &gt; I would appreciate any suggestions, remarks or other inputs.<br>
&gt; &gt; Thank you very much for your reply.<br>
&gt;<br>
&gt; Should you need any other clarification wrt to some of the points<br>
&gt; above, just ask.<br>
<br>
</span>Thank you for your input.<br>
<br>
Jan Černý<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; Thank you &amp;&amp; Regards, Jan<br>
&gt; --<br>
&gt; Jan iankko Lieskovsky / Red Hat Security Technologies Team<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Regards<br>
&gt; &gt;<br>
&gt; &gt; Jan Černý<br>
&gt; &gt; Security Technologies | Red Hat, Inc.<br>
&gt; &gt; --<br>
&gt; &gt; SCAP Security Guide mailing list<br>
&gt; &gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt; &gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" rel="noreferrer" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
&gt; &gt; <a href="https://github.com/OpenSCAP/scap-security-guide/" rel="noreferrer" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a><br>
&gt;<br>
--<br>
SCAP Security Guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" rel="noreferrer" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
<a href="https://github.com/OpenSCAP/scap-security-guide/" rel="noreferrer" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a></div></div></blockquote></div><br></div>