Provide implementation of "create_config_keys_set.py" OVAL template

[iankko]

Existing OVAL templates are:

• lowering the enter barrier for potential SSG contributors
  (since they don't require exact knowledge of particular OVAL constructs),
• radically increasing the speed in which new OVAL checks can be contributed
  (since it's enough to edit corresponding CSV file, and run corresponding make target
  to obtain new OVAL definition implementation for that product)

Since the textfilecontent54_object is the most utilized one in SSG content
(for demonstration this is the current output from RHEL/6 product:

$ ./count_oval_objects.py scap-security-guide/RHEL/6/output/ssg-rhel6-xccdf.xml
...
Count of used OVAL objects:
==================================================
textfilecontent54_object                        47
partition_object                                10
runlevel_object                                  7
file_object                                      5
rpminfo_object                                   3
variable_object                                  2
xmlfilecontent_object                            1
environmentvariable58_object                     1
selinuxsecuritycontext_object                    1
interface_object                                 1

) we should consider implementation of OVAL template for the OVAL's textfilecontent54_test construct.

Please see the expectations / requirements on this template below:

• the corresponding CSV, AST, whatever file should allow comments,
• the template should be smart enough not to require all of the necessary element and / or attribute values to be provided (just those that would truly need updating. The rest of the element / attribute values should be prepopulated with default OVAL values from corresponding XSD,
• on the other hand the template should be flexible enough to allow:
  • override default values of selected attributes in an element, for example having the default form of <ind:instance> element reading like:
    <ind:instance datatype="int" operation="equals">1</ind:instance>
    by specifying e.g. operation@instance="greater than or equal this default form would translate into:
    <ind:instance datatype="int" operation="greater than or equal">1<ind:instance>
  • be also flexible enough to allow:
    • external variables to be specified,
  • extended definitions to be specified,
  • and even (but this can be implemented in the future even multiple tests and multiple
    objects to be specified)

Since the above requirements are pretty wide scoped, CSV template format might not be the right one to implement this.

During proposing the expected interface for this I was thinking if we could hopefully use Python's AST's module literal_eval helper:
    [1] https://docs.python.org/2/library/ast.html#ast.literal_eval
to convert the AST (current CSV) content specification into Python object, then use some deserialization method to convert such Python dictionary into a XML representation:

• either using means of dicttoxml module or

• using own method for that purpose. See e.g.:
  [2] http://code.activestate.com/recipes/573463-converting-xml-to-dictionary-and-back/

  for example.

[iankko]

Should we try to define how such aggregated OVAL template form should look like, let's look on the two different representatives of that check in current content:

• 1. shared/oval/selinux_policytype.xml (using object + state + external variable)

<def-group>
  <definition class="compliance" id="selinux_policytype" version="1">
    <metadata>
      <title>Enable SELinux</title>
      <affected family="unix">
        <platform>multi_platform_rhel</platform>
      </affected>
      <description>The SELinux policy should be set appropriately.</description>
      <reference source="MED" ref_id="20130819" ref_url="test_attestation" />
      <!-- RHEL7 <reference source="SDW" ref_id="20131222" ref_url="test_attestation" /> -->
    </metadata>
    <criteria>
      <criterion test_ref="test_selinux_policy" />
    </criteria>
  </definition>

  <ind:textfilecontent54_test check="all" check_existence="all_exist"
  comment="Tests the value of the ^[\s]*SELINUXTYPE[\s]*=[\s]*([^#]*) expression in the /etc/selinux/config file"
  id="test_selinux_policy" version="1">
    <ind:object object_ref="obj_selinux_policy" />
    <ind:state state_ref="state_selinux_policy" />
  </ind:textfilecontent54_test>

  <ind:textfilecontent54_state id="state_selinux_policy" version="1">
    <ind:subexpression operation="equals" var_check="all"
    var_ref="var_selinux_policy_name" />
  </ind:textfilecontent54_state>

  <external_variable comment="External variable: name of selinux policy in /etc/selinux/config"
  datatype="string" id="var_selinux_policy_name" version="1" />

  <ind:textfilecontent54_object id="obj_selinux_policy" version="1">
    <ind:filepath>/etc/selinux/config</ind:filepath>
    <ind:pattern operation="pattern match">^[\s]*SELINUXTYPE[\s]*=[\s]*([^\s]*)</ind:pattern>
    <ind:instance datatype="int">1</ind:instance>
  </ind:textfilecontent54_object>
</def-group>

• 2. shared/oval/require_smb_client_signing.xml (using extended OVAL definition)

<def-group>
  <definition class="compliance" id="require_smb_client_signing" version="1">
    <metadata>
      <title>Require Client SMB Packet Signing in smb.conf</title>
      <affected family="unix">
        <platform>multi_platform_rhel</platform>
      </affected>
      <description>Require samba clients which use smb.conf, such as smbclient,
      to use packet signing. A Samba client should only communicate with
      servers who can support SMB packet signing.</description>
      <reference source="galford" ref_id="20160120" ref_url="test_attestation" />
    </metadata>
    <criteria operator="OR">
      <extend_definition comment="package samba-common is not installed"
      definition_ref="package_samba-common_removed" />
      <criterion comment="check for client signing = mandatory in /etc/samba/smb.conf"
      test_ref="test_require_smb_client_signing" />
    </criteria>
  </definition>

  <ind:textfilecontent54_test check="all" check_existence="at_least_one_exists"
  comment="check for client signing = mandatory in /etc/samba/smb.conf"
  id="test_require_smb_client_signing" version="1">
    <ind:object object_ref="obj_require_smb_client_signing" />
  </ind:textfilecontent54_test>

  <ind:textfilecontent54_object id="obj_require_smb_client_signing"
  version="1">
    <ind:filepath>/etc/samba/smb.conf</ind:filepath>
    <ind:pattern operation="pattern match">^[\s]*client[\s]+signing[\s]*=[\s]*mandatory</ind:pattern>
    <ind:instance datatype="int">1</ind:instance>
  </ind:textfilecontent54_object>
</def-group>

Therefore such an OVAL template (using default value "None") could look like (possibly adding also other default attributes from Independent schema where appropriate):

<def-group>
  <definition class="compliance" id="None" version="1">
    <metadata>
      <title>None</title>
      <affected family="unix">
        <platform>None</platform>
      </affected>
      <description>None</description>
      <reference source="None" ref_id="None" ref_url="test_attestation" />
    </metadata>
    <criteria operator="AND">
      <extend_definition comment="None" definition_ref="None" />
      <criterion test_ref="None" />
    </criteria>
  </definition>

  <ind:textfilecontent54_test check="all" check_existence="all_exist" comment="None"
  id="None" version="1">
    <ind:object object_ref="None" />
    <ind:state state_ref="None" />
  </ind:textfilecontent54_test>

  <ind:textfilecontent54_state id="None" version="1">
    <ind:subexpression operation="equals" var_check="all" var_ref="None" />
  </ind:textfilecontent54_state>

  <ind:textfilecontent54_object id="None" version="1">
    <ind:path>None<ind:path>
    <ind:filename operation="pattern match">None<ind:path>
    <ind:filepath>None</ind:filepath>
    <ind:pattern operation="pattern match">None</ind:pattern>
    <ind:instance datatype="int">1</ind:instance>
  </ind:textfilecontent54_object>

  <external_variable comment="None" datatype="None" id="None" version="1" />

</def-group>

The corresponding config_keys_set.csv file might have the following entry ({ character is understood to represent start of the definition, } it's end -- since the definition content might be multilined):

# Definition of /shared/oval/selinux_policytype.xml

{
  id@definition = "selinux_policytype",
  title="Enable SELinux",
  platform="multi_platform_rhel",
  description="The SELinux policy should be set appropriately.",
  source@reference="MED", ref_id@reference="20130819", 
  comment@ind:textfilecontent54_test="Desired comment",
  comment@external_variable="External variable: name of selinux policy in /etc/selinux/config",
  ind:filepath="/etc/selinux/config",
  ind:pattern="^[\s]*SELINUXTYPE[\s]*=[\s]*([^\s]*)"
}

# Definition of shared/oval/require_smb_client_signing

{
  id@definition="require_smb_client_signing",
  title="Require Client SMB Packet Signing in smb.conf",
  platform="multi_platform_rhel",
  description="Require samba clients ...",
  source@reference="galford",
  ref_id@reference="20160120",
 operator@criteria="OR",
  comment@extend_definition="package samba-common is not installed",  
  definition_ref@extend_definition="package_samba-common_removed",
  comment@criterion="check for client signing = mandatory in /etc/samba/smb.conf", 
  check_existence@ind:textfilecontent54_test="at_least_one_exists", 
  comment@ind:textfilecontent54_test="check for client signing = mandatory in /etc/samba/smb.conf",
 ind:filepath="/etc/samba/smb.conf",
ind:pattern="^[\s]*client[\s]+signing[\s]*=[\s]*mandatory"
}

Hopefully by selecting reasonable enough default values we could even simplify the aforementioned notation to less characters. Maybe the default value of <title> and <description> elements could be generated by the tool too, e.g:

• title e.g. Require key in filepath ```set.
• description e.g. The key in filepathshould be set to appropriately.

The ``create_config_keys_set.py` helper would then automatically perform the following (pre-populate the content for attributes with known values, e.g)

• assign result of concatenation of `testandid@definition``to``test_ref@criterion``,
• assign result of concatenation of obj and id@definition to both object_ref@ind:object and id@ind:textfilecontent54_object,
• assign result of concatenation of ste and id@definition to both state_ref@ind:state and id@textfilecontent54_state,
• assign result of concatenation of var and id@definition to id@external_variable if so far external_variable contains some non-null attribute (e.g. it's content attribute was set -- we intend to use the external_variable),

Also the create_config_keys_set.py prior writing the final version of the OVAL check would delete all rows having at least one element / attribute still containing "None" value.

Also if the user would want to override value of some attribute for some element, they would specify it and the template value would be overwritten
(see the example check_existence@ind:textfilecontent54_test
for the case of require_smb_client_signing above

[mpreisler]

I don't think it's wise to make a template that is powerful. Let's make one that is simple and can do 90% of what we need to do with textfilecontent54 probe. The rest can be done with raw OVAL. Specifically, let's avoid all the OVAL lingo and conventions here and design something that people who don't know OVAL can use.

Most of the time we are checking that a single file contains a line that matches some regex. I think that is a good start. I'd prefer to have multiple simple focused templates to having one that can do it all but is only marginally less complex than writing OVAL.

[redhatrises]

I wonder if it would be easier/faster if we made all XCCDF and OVAL content initially as python dicts and then convert to the appropriate XML configuration in the backend. Kind of what @iankko suggested but with a few tweaks. For example:

Sample OVAL file:

name="require_smb_client_signing",
title="Require Client SMB Packet Signing in smb.conf",
platform="multi_platform_rhel",
description="Require samba clients ...",
reference="galford",
reference_date="20160120",
criteria="OR",
extend_definition=package_samba-common_removed",
comment="some comments",
check_existence="at_least_one_exists", 
file="/etc/samba/smb.conf",
regex="^[\s]*client[\s]+signing[\s]*=[\s]*mandatory"
....

Sample XCCDF:

name="enable_selinux_bootloader"
title="Ensure SELinux...."
description="SELinux can be ..."
ocil_clause="SELinux is disabled"
ocil_text="Inspect ..."
rationale="Some rationale ..."
....

Then for any super advanced OVAL, use original xml content.

[iankko]

I wonder if it would be easier/faster if we made all XCCDF and OVAL content initially as
python dicts and then convert to the appropriate XML configuration in the backend.

Looks like pretty straightforward way. +1 on this.

IMHO the current CSV approach (applied in create packages installed etc) OVAL checks would be hardly to be used, since for <ind:textfilecontent54_object there are many possible attributes, that could be reset against the default element / attribute value.

And we want to avoid the content creator to need to specify all values. They should specify just those, that would differ from the default ones.

[iankko]

Another possible approach:

• Use PyXB (shipped in Fedora at least) to convert XSD to Python's independent.py module
  Having:
  • https://oval.mitre.org/language/version5.11/ovaldefinition/minimal/independent-definitions-schema.xsd
  • https://oval.mitre.org/language/version5.11/ovaldefinition/minimal/oval-common-schema.xsd
  • https://oval.mitre.org/language/version5.11/ovaldefinition/minimal/oval-definitions-schema.xsd and
  • https://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd

present in the CWD, create independent.py module via:

$ pyxbgen -u oval-definitions-schema.xsd -m independent

then use that independent.py module to create Python dictionary object for ind:textfilecontent54_test (maybe it would be even possible to create object for definition specifying textfilecontent54_test should be used there). Load sample content provided in:
#1083 (comment)

into second Python dictionary. Merge the dictionaries e.g. via:

• http://stackoverflow.com/q/38987
• http://stackoverflow.com/a/26853961

Finally deserialize the final / merged dictionary into final XML file.

[mpreisler]

I will reiterate that just switching XSD for Python dicts is not what we need. It makes things a little bit easier for OVAL experts (that's @iankko and @redhatrises for example). It doesn't make things any easier for new contributors. I would say the opposite actually. Before they could at least see examples online of how to write OVAL, they won't see any examples of the new syntax we are creating here.

[iankko]

So you suggest having multiple templates like:

• textfilecontent54_OVAL_basic (just one textfilecontent54 test with one textfilecontent54_object) specifying:
  id, platform, filepath (or combination file + path), regex, title, description

• textfilecontent54_OVAL_with_state (one textfilecontent54_test + object + state) specifying:

  id, platform, obj_filepath (or combination file + path), obj_regex, ste_filepath, ste_regex, title, description,

• textfilecontent54_OVAL_with_state_and_ext_var specifying:

  id, platform, obj_filepath (or combination file + path), regex, ste_var_ref, title, description

, and possibly also

• textfilecontent54_OVAL_with_extend_def specifying

  id, platform, obj_filepath (or combination file + path), regex, ext_def_id, title, description

Even if this is the case it would be improvement when compared with current state.

[mpreisler]

What about: file_contains_regex? That sort of thing, just keep the OVAL behind the scenes.

[iankko]

Makes sense to me. ACK.

[redhatrises]

It doesn't make things any easier for new contributors.

Mmmmm..... I wonder if a grander objective would be to create a UI/GUI that would abstract most of the nitty gritty stuff and generate OVAL/XCCDF/remediation content very easily/quickly rather than a bunch of scripts/templates. Maybe a new OpenSCAP project called scap-creator which is similar to scap-workbench, but it creates OVAL/XCCDF/remediation content.

[iankko]

• As for the name I would recommend / vote for "ssg-editor".
• As for the GUI iface - current OVAL templates (without interactivity) IMHO are more straightforward for CLI processing,
• As for the future, and interactive GUI would be helpful (the plan was to create this once we have all the templates for various probes available / implemented). The GUI wrapper just to use those, not to need to perform syntax checking itself. So I would say it's still makes sense to create the non-interactive templates.

Just my 2C.