Anyone using rhel6 ssg for centos6?

Greg Elin gregelin at gitmachines.com
Fri Aug 15 20:05:52 UTC 2014


(Sorry - hit sent accidentally)

Thanks everyone for contributing to this thread. It's been very helpful.

I have had a few draft replies, but let me try to keep things short.

Many of the contributions address altering the files in the source
Scap-security-guide repo. It would be great to have an upstream resolution
so those installing OpenSCAP and SSG can do so via RPM (or repo) and
confidently work across Fedora, RedHat, and CentOS. (Separating CentOS
seems might have some nuances to consider because often us users substitute
CentOS for RedHat and we may want to see "RedHat" showing up in results.)

I am still interested in how to fix the issue with the files I have
installed via RPMs. I'm a little weak still on the whole build thing to be
honest. But more importantly, I *want* to be aligned with what is being
distributed. I want to have GovReady install OpenSCAP and SSG and then use
it. I'm reluctant to fork the source SSG.

So with that in mind, I got this working. I added a new
centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe
dictionary can be referenced in oscap command line and it points to the
correct centos6-cpe-oval.xml file that has a modified test for CentOS.

The changes that needed to be made seem to come down to changing
`redhat-release-server` (and/or `redhat-release-workstation`) to
`centos-release` and changing the pattern match on the version from
`^6\.\d+$` to `^6`.

Two file attached.

ssg-centos6-cpe-dictionary.xml:

```
<cpe-list xmlns="http://cpe.mitre.org/dictionary/2.0" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://cpe.mitre.org/dictionary/2.0
http://cpe.mitre.org/files/cpe-dictionary_2.1.xsd">
      <cpe-item name="cpe:/o:redhat:enterprise_linux:6">
            <title xml:lang="en-us">Red Hat Enterprise Linux 6</title>
            <!-- the check references an OVAL file that contains an
inventory definition -->
            <check system="
http://oval.mitre.org/XMLSchema/oval-definitions-5"
href="ssg-centos6-cpe-oval.xml">oval:ssg:def:100</check>
      </cpe-item>
</cpe-list>
```

 ssg-centos6-cpe-dictionary.xml excerpts (emphasis added):

```
  <definitions>
    <definition class="inventory" id="oval:ssg:def:100" version="1">
      <metadata>
        <title>CentOS Linux 6</title>
        <affected family="unix">
          <platform>CentOS Linux 6</platform>
        </affected>
        <reference ref_id="cpe:/o:redhat:enterprise_linux:6" source="CPE"/>
        <description>The operating system installed on the system is
      CentOS Linux 6</description>
      </metadata>
      <criteria>
        <criterion comment="Installed operating system is part of the unix
family" test_ref="oval:ssg:tst:101"/>
        *<criterion comment="Installed operating system is CentOS 6"
test_ref="oval:ssg:tst:110"/>*
      </criteria>
    </definition>
  </definitions>
```

```
  <tests>

    </ind:family_test>
     *<linux:rpminfo_test check="all" check_existence="at_least_one_exists"
comment="centos-release is installed" id="oval:ssg:tst:110" version="1">*
*       <linux:object object_ref="oval:ssg:obj:108"/>*
*       <linux:state state_ref="oval:ssg:ste:109"/>*
*     </linux:rpminfo_test>*
  </tests>
  <objects>
    <ind:family_object id="oval:ssg:obj:104" version="1"/>
    <linux:rpminfo_object id="oval:ssg:obj:106" version="1">
      <linux:name>redhat-release-workstation</linux:name>
    </linux:rpminfo_object>
    *<linux:rpminfo_object id="oval:ssg:obj:108" version="1">*
*      <linux:name>centos-release</linux:name>*
*    </linux:rpminfo_object>*
  </objects>
  <states>
    <ind:family_state id="oval:ssg:ste:105" version="1">
      <ind:family>unix</ind:family>
    </ind:family_state>
    *<linux:rpminfo_state id="oval:ssg:ste:109" version="1">*
*      <linux:version operation="pattern match">^6</linux:version>*
*    </linux:rpminfo_state>*
  </states>
</oval_definitions>
```

Greg Elin
http://govready.org - Making FISMA compliance easier for innovators

email: gregelin at gitmachines.com
phone: 917-304-3488




On Fri, Aug 15, 2014 at 3:59 PM, Greg Elin <gregelin at gitmachines.com> wrote:

> Thanks everyone for contributing to this thread. It's been very helpful.
>
> I have had a few draft replies, but let me try to keep things short.
>
> Many of the contributions address altering the files in the source
> Scap-security-guide repo. It would be great to have an upstream resolution
> so those installing OpenSCAP and SSG can do so via RPM (or repo) and
> confidently work across Fedora, RedHat, and CentOS. (Separating CentOS
> seems might have some nuances to consider because often us users substitute
> CentOS for RedHat and we may want to see "RedHat" showing up in results.)
>
> I am still interested in how to fix the issue with the files I have
> installed via RPMs. I'm a little weak still on the whole build thing to be
> honest. But more importantly, I *want* to be aligned with what is being
> distributed. I want to have GovReady install OpenSCAP and SSG and then use
> it. I'm reluctant to fork the source SSG.
>
> So with that in mind, I got this working. I added a new
> centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe
> dictionary can be referenced in oscap command line and it points to the
> correct centos6-cpe-oval.xml file that has a modified test for CentOS.
>
> The changes that needed to be made seem to come down to changing
> `redhat-release-server` (and/or `redhat-release-workstation`) to
> `centos-release` and changing the pattern match on the version from
> `^6\.\d+$
>
>
>
>
>
>
> On Fri, Aug 15, 2014 at 3:39 PM, Shane Shaffer <shane.shaffer at g2-inc.com>
> wrote:
>
>> While you're on the right track with a workaround, there is an important
>> clarification to how it all works.
>>
>>>
>>>
>>> Step 1: In your OVAL check, you define which platforms the check is
>>> written for. This is done by the <affected> stanzas, such as:
>>>
>>> >       <affected family="unix">
>>> >         <platform>Red Hat Enterprise Linux 6</platform>
>>> >       </affected>
>>>
>>>
>>> Step 2: When an SCAP interpreter parses each OVAL rule, it will parse
>>> the <affected> tag above. For each <platform> listed, it will find the
>>> associated <cpi-item> to find what <check> needs to be ran. This will
>>> tell the SCAP interpreter if the OVAL rule is applicable for the system
>>> being scanned.
>>>
>>>
>> Actually the affected/platform/product tags in the OVAL content are
>> meaningless to processing. According to the OVAL spec:
>>
>> "Each OVAL Definition is written to evaluate a certain type of system(s).
>> The family, platform(s), and product(s) of this target are described by the
>> AffectedType whose main purpose is to provide hints for tools using OVAL
>> Definitions. For instance, to help a reporting tool only use Windows
>> definitions, or to preselect only Red Hat definitions to be evaluated.
>> Note, the inclusion of a particular platform or product does not mean the
>> definition is physically checking for the existence of the platform or
>> product. For the actual test to be performed, the correct test must still
>> be included in the definition's criteria section.
>>
>> The AffectedType complex type details the specific system, application,
>> subsystem, library, etc. for which a definition has been written. If a
>> definition is not tied to a specific product, then this element should not
>> be included. The absence of the platform or product element can be thought
>> of as definition applying to all platforms or products. The inclusion of a
>> particular platform or product does not mean the definition is physically
>> checking for the existence of the platform or product. For the actual test
>> to be performed, the correct test must still be included in the
>> definition's criteria section. To increase the utility of this element,
>> care should be taken when assigning and using strings for product names.
>> The schema places no restrictions on the values that can be assigned,
>> potentially leading to many different representations of the same value.
>> For example, 'Internet Explorer' and 'IE' might be used to refer to the
>> same product. The current convention is to fully spell out all terms, and
>> avoid the use of abbreviations at all costs.
>>
>> So while the intent is to identify the applicable platform/product, what
>> is listed there need not have any bearing on whether or not the content is
>> executed. An OVAL interpreter could try to leverage this data to avoid
>> running inappropriate content, but it is perfectly legal to execute the
>> RHEL6 OVAL content on a Windows box, for example.
>>
>> It is actually only the platform tags in XCCDF that behave as you've
>> described. The id_ref in the platform tag is looked up in the CPE
>> Dictionary file, the corresponding definition in the CPE OVAL file is
>> evaluated, if that returns true then the Benchmark/Group/Rule (wherever the
>> platform tag is located) is deemed applicable.
>>
>> Bottom line, the workaround is correct, but the OVAL content outside of
>> the CPE OVAL content doesn't play a part in the issue unless the OVAL
>> interpreter used makes it an issue.
>>
>>
>> --
>> SCAP Security Guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>> https://github.com/OpenSCAP/scap-security-guide/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140815/223fa098/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssg-centos6-cpe-dictionary.xml
Type: text/xml
Size: 602 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140815/223fa098/attachment-0002.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssg-centos6-cpe-oval.xml
Type: text/xml
Size: 3057 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140815/223fa098/attachment-0003.xml>


More information about the scap-security-guide mailing list