Common OVAL code (like for asserting for uninstalled services)

Simon Lukasik isimluk at fedoraproject.org
Mon Aug 5 14:12:40 UTC 2013


On 08/05/2013 03:22 PM, Shawn Wells wrote:
> On 8/1/13 12:37 PM, Simon Lukasik wrote:
>> Hello,
>>
>> Recently we have significantly improved handling of OVAL variables in
>> OpenSCAP.
>>
>> I believe that SSG can leverage this improved handling to avoid
>> redundancies (or similar code snippets). And significantly reduce the
>> size of the OVAL definition file (and consequently the size of OVAL
>> results).
>>
>> I understand that it might not be a top priority, so this is just a
>> heads-up.
>>
>> Example: There are definitions asserting that a service X is not
>> installed. If you manage to refactor the service X to a variable you can
>> the use the very same definition/test/item/object for many services. The
>> evaluation results will be then distinguished by @variable_instance
>> attribute and by tested_variable sub-element.
>>
>> So, where you can start reading? Firstly, we have a general write-up
>> regarding variable processing at
>>
>>
>> http://www.open-scap.org/page/Documentation#Notes_on_the_Concept_of_Multiple_OVAL_Values
>>
>> Secondly, there are some tests in OpenSCAP repo which demonstrate the
>> usage of the variables:
>>
>>
>> https://git.fedorahosted.org/cgit/openscap.git/tree/tests/API/XCCDF/variable_instance
> 
> In reviewing the example code, it looks like if we had 20 variable
> elements (e.g. 20 service names), there would need to be 20
> corresponding XCCDF rules:
> 
>> |  <Rule id="xccdf_moc.elpmaxe.www_rule_2" selected="false">
>>     <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
>>       <check-export value-id="xccdf_moc.elpmaxe.www_value_1" export-name="oval:com.example.www:var:1"/>
>>       <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/>
>>     </check>
>>   </Rule>
>>   <Rule id="xccdf_moc.elpmaxe.www_rule_3" selected="false">
>>     <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
>>       <check-export value-id="xccdf_moc.elpmaxe.www_value_2" export-name="oval:com.example.www:var:1"/>
>>       <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/>
>>     </check>
>>   </Rule>|
> 
> Is it possible for a SCAP scanner to parse all variables in a single
> XCCDF rule? e.g.:
>> |  <Rule id="xccdf_moc.elpmaxe.www_rule_2" selected="false">
>>     <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
>>       <check-export value-id="xccdf_moc.elpmaxe.www_value_[@]" export-name="oval:com.example.www:var:1"/>
>>       <check-content-ref href="requires_both-oval.xml" name="oval:com.example.www:def:1"/>
>>     </check>
>>   </Rule>
>> |
> 

Yes, that could be possible (although I did not test).

You can use one <xccdf:check> with 20 <check-export> elements. All of
them will bind different XCCDF values to the very same OVAL variable.

  <check (...)
      <check-export value-id="xccdf_moc.elpmaxe.www_value_1"
                    export-name="oval:com.example.www:var:1"/>
      <check-export value-id="xccdf_moc.elpmaxe.www_value_2"
                    export-name="oval:com.example.www:var:1"/>
      <check-export value-id="xccdf_moc.elpmaxe.www_value_3"
                    export-name="oval:com.example.www:var:1"/>
      (...)
      <check-content-ref href="my-oval.xml"
                         name="oval:com.example.www:def:1"/>
  </check>

Then, if you generate OVAL variables document from such XCCDF (# oscap
xccdf export-oval-variables), it will give you something like:

    <variable id="oval:com.example.www:var:1"/>
       <value>abrt</value>
       <value>acpid</value>
       <value>certmonger</value>
       (...)
    </variable>

Then, You only need to write OVAL definition with meaning: None of the
services given by variable is installed/enabled. While that is possible,
I would not recommend that. Having a single XCCDF Rule per service seems
to be good choice of granularity to me.

Best regards,

--
Simon Lukasik
Security Technologies




More information about the scap-security-guide mailing list