Add RHCOS4 product

[JAORMX]

No description provided.

[JAORMX]

need to fix the cce's

[JAORMX]

/ok-to-test

[redhatrises]

Totally agree with this PR. One thought I have is that "CoreOS is RHEL" so why make it a separate product from RHEL since it implements everything as RHEL anyway.

[evgenyz]

Totally agree with this PR. One thought I have is that "CoreOS is RHEL" so why make it a separate product from RHEL since it implements everything as RHEL anyway.

Sorry, but that is not true, RHCOS ≠ RHEL. For example, RHCOS follows https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ and RHEL does not. As the result, despite the fact that both OSes use the same GRUB2 bootloader, configuration is different. All rules that use 'grub2_bootloader_argument' template are not applicable to RHCOS. See #5285.

[JAORMX]

haven't gotten a chance to get this working. I'll get back to it next week.

[redhatrises]

Totally agree with this PR. One thought I have is that "CoreOS is RHEL" so why make it a separate product from RHEL since it implements everything as RHEL anyway.

Sorry, but that is not true, RHCOS ≠ RHEL. For example, RHCOS follows https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ and RHEL does not. As the result, despite the fact that both OSes use the same GRUB2 bootloader, configuration is different. All rules that use 'grub2_bootloader_argument' template are not applicable to RHCOS. See #5285.

@evgenyz thanks. Preaching to the choir. While the technical people here understand that, this is Red Hat's (whether we agree or not) current statement.

[yuumasato]

Sorry, but that is not true, RHCOS ≠ RHEL. For example, RHCOS follows https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ and RHEL does not. As the result, despite the fact that both OSes use the same GRUB2 bootloader, configuration is different.

Although RHEL8 doesn't follow BLS to the letter, the way to configure it is the same.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index#booting-process_kernel

https://access.redhat.com/solutions/3799961

[evgenyz]

Although RHEL8 doesn't follow BLS to the letter, the way to configure it is the same.

Exactly because they don't follow it to the letter the configuration is different. For example BLS does not contain a word about variables in configuration files, thus getting kernel arguments for BLS-compatible configuration is as easy as reading options line in /boot/loader/entries/*.conf. In RHEL and Fedora this line could contain something like $kernelopts, which you have to hunt down somewhere else (and truly BLS-compatible boot loader will load garbage as kernel arguments for this entry).

So, no, not compatible. If not to the letter, then not at all.

@yuumasato I'm sorry, I accidentally edited your comment instead of quoting. And I don't have a email with its contents, so I can't restore it :( Found it.

[JAORMX]

/retest

[yuumasato]

Exactly because they don't follow it to the letter the configuration is different. For example BLS does not contain a word about variables in configuration files, thus getting kernel arguments for BLS-compatible configuration is as easy as reading options line in /boot/loader/entries/*.conf. In RHEL and Fedora this line could contain something like $kernelopts, which you have to hunt down somewhere else (and truly BLS-compatible boot loader will load garbage as kernel arguments for this entry).

So, no, not compatible. If not to the letter, then not at all.

@evgenyz Very well put.

These particularities can make it hard to maintain good content for both OSes if treated as a single product. It is probably best to keep RHEL and RHCOS two separate products.

[yuumasato]

I haven't checked applicability of the rules, but overall looks good to me.

[JAORMX]

/test all

[jhrozek]

I'll continue the review later today

[jhrozek]

Instead of extending the RHEL-8 test, should we remove the following from the RHEL-8 oval check:

  <ind:textfilecontent54_test check="all" comment="redhat-release-coreos is version 8" id="test_rhel8_coreos" version="1">
    <ind:object object_ref="obj_rhel8_coreos" />
    <ind:state state_ref="state_rhel8_coreos" />
  </ind:textfilecontent54_test>
  <ind:textfilecontent54_object id="obj_rhel8_coreos" version="1">
    <ind:filepath>/etc/os-release</ind:filepath>
    <ind:pattern operation="pattern match">^PRETTY_NAME=&quot;Red Hat Enterprise Linux CoreOS \d+\.(\d)\d+\.[\d\.\-]+ \([\w\s]+\)&quot;$</ind:pattern>
    <ind:instance operation="greater than or equal" datatype="int">1</ind:instance>
  </ind:textfilecontent54_object>
  <ind:textfilecontent54_state id="state_rhel8_coreos" version="1">
    <ind:subexpression operation="pattern match">8</ind:subexpression>
  </ind:textfilecontent54_state>

and move it to this file instead? Or are there some other cases where we want to treat RHCOS as RHEL?

[JAORMX]

not necessarily, but currently the "RHEL" check contains an RHCOS check, we need to change that but I think it should be done in a subsequent PR.

[jhrozek]

I literally have zero idea what this file is for, but several of the items in this file will never be present on a RHCOS host, at least not in the OCP context (gdm, nss-pam-ldapd, yum, ...)

[JAORMX]

@yuumasato @ggbecker any idea what's up with this file? I merely copied it from the ocp product.

[ggbecker]

in ComplianceAsCode we use to limit applicability of certain checks using the platform: keyword within rule.yml files:

Check this excerpt from the developer_guide.adoc:

platform: Defines applicability of a rule. For example, if a rule is not applicable to containers, 
this should be set to machine, which means it will be evaluated only if the targeted scan 
environment is either bare-metal or virtual machine. Also, it can restrict applicability on higher 
software layers. By setting to shadow-utils, the rule will have its applicability restricted to only 
environments which have shadow-utils package installed. The available options can be found 
in the file <product>/cpe/<product>-cpe-dictionary.xml (e.g.: rhel8/cpe/rhel8-cpe-dictionary.xml).
 In order to support a new value, an OVAL check (of inventory class) must be created under 
shared/checks/oval/ and referenced in the dictionary file.
``

[yuumasato]

When this line is like this:
'rhcos': 'Red Hat Enterprise Linux CoreOS release',

The build process includes OVALs included by affected_platform, like auditd_data_retention_flush.

What happens is that in is_applicable_for_product() https://github.com/ComplianceAsCode/content/blob/master/ssg/utils.py#L123, it tries to reconstruct the full name of the product, which in rhcos4/product.yml is defined with trailing release.

Now I wonder how much the word release is actually really part of the name.
Should the product full_name in rhcos4/product.yml be Red Hat Enterprise Linux CoreOS 4?

[JAORMX]

let's give it a try

[mildas]

Changes identified:
Rule checks:
 The rule doesn't occur in any profile nor product.
 OVAL check is newly added.
Profile coreos-ncp on rhcos4:
 Newly added profile.
Profile e8 on rhcos4:
 Newly added profile.
Profile moderate on rhcos4:
 Newly added profile.
Others:
 Python abstract syntax tree change found in ssg/constants.py.

Recommended tests to execute:
 build_product rhcos4
 tests/test_suite.py profile --libvirt qemu:///system test-suite-vm --datastream build/ssg-rhcos4-ds.xml coreos-ncp
 tests/test_suite.py profile --libvirt qemu:///system test-suite-vm --datastream build/ssg-rhcos4-ds.xml e8
 tests/test_suite.py profile --libvirt qemu:///system test-suite-vm --datastream build/ssg-rhcos4-ds.xml moderate
 (cd build && cmake ../ && ctest -j4)

[JAORMX]

/retest

unrelated CI issue

[JAORMX]

/test all

CI issues...

[JAORMX]

/retest

[JAORMX]

@redhatrises could you check this out?

[redhatrises]

Looks like there are subsequent follow on PRs, so merging this to support the follow-on fixes and work.