add new product openeuler supporting

[StevenYGui]

I closed a previous PR, because there are some conflicts.
For more info for this PR, please refer #11272
Thank you for your attention.

Description:

• OpenScap is a well-known security configuration baseline scanning organization in the industry. The tools provided by OpenScap provide security scanning functions for most operating systems around the world. OpenEuler also hopes to join the OpenScap family and use the powerful functions of OpenScap to complete and provide security configuration baseline scanning capabilities.

• The openEuler community, known as the OpenAtom openEuler community, is an open source community for operating systems. The openEuler or openEuler community is incubated and operated by the Open Atomic Open Source Foundation.

• The openEuler operating system supports application scenarios such as servers, cloud computing, edge computing, and embedded computing, and supports diversified computing. It is committed to providing a secure, stable, and easy-to-use operating system. Support OT applications and the integration of OT and ICT by providing qualitative assurance capabilities for applications.

• Through an open community, the openEuler community works with global developers to build an open, pluralistic and inclusive software ecosystem. Incubate and support a variety of processor architectures, cover the whole scene of the word infrastructure, and promote the development of the software and hardware of the enterprise's word infrastructure and the application ecology.

• As of June 2023, the number of openEuler community members exceeded 970 and the number of community downloads exceeded 1.45 million. With more than 14,000 developers, its living global contributors are likely to continue to promote the global ecology of openEuler.

• openeuler2203 is a long term support version of openEuler.

Rationale:

This pr contains two code submissions. One is to build the openEuler-related support framework, and the other is to add common openEuler check items.

Review Hints:

Please review it and any feedback is my appreciate.

[openshift-ci]

Hi @StevenYGui. Thanks for your PR.

I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[github-actions]

Start a new ephemeral environment with changes proposed in this pull request:

rhel8 (from CTF) Environment (using Fedora as testing environment)

Fedora Testing Environment

Oracle Linux 8 Environment

[vojtapolasek]

Hello and thank you, continuing my feedback from the previous PR.

1. Please modify the policy file so that the IDs of controls contain numbers only. There is no need for words, they are contained in the title. e.g. it is enough to have

id: 1.1.1

instead of

id: 1.1.1_no_unowner_ungroup_files

2. I would strongly consider keeping only versioned products. That means, I think that the "openeuler" product without numbering should not be added. It might seem like a good idea, but imagine that something (filename, file structure) gets changed along the Openeuler development and the rule would become broken. It would be necessary to restrict applicability of such a rule with platforms. I admit this can happen even for versioned products, but the chance is lower.

What do you think about this?

[StevenYGui]

Hello and thank you, continuing my feedback from the previous PR.

1. Please modify the policy file so that the IDs of controls contain numbers only. There is no need for words, they are contained in the title. e.g. it is enough to have

id: 1.1.1

instead of

id: 1.1.1_no_unowner_ungroup_files

2. I would strongly consider keeping only versioned products. That means, I think that the "openeuler" product without numbering should not be added. It might seem like a good idea, but imagine that something (filename, file structure) gets changed along the Openeuler development and the rule would become broken. It would be necessary to restrict applicability of such a rule with platforms. I admit this can happen even for versioned products, but the chance is lower.

What do you think about this?

thanks for your quickly response, I removed version of "openeuler", and changed the rules id to numbers only, please check it again, thank you very much.

[vojtapolasek]

Hello @StevenYGui , could you please rebase the branch on the latest master? There is a fix for one of checks which are required to pass before I can merge the PR. In the mean time I will be reviewing the PR. Thank you.

[vojtapolasek]

LGTM, please rebase.

[StevenYGui]

Hello @StevenYGui , could you please rebase the branch on the latest master? There is a fix for one of checks which are required to pass before I can merge the PR. In the mean time I will be reviewing the PR. Thank you.

yes, I rebased it, and waiting for the checking finished, thanks.

[vojtapolasek]

Hello @StevenYGui and sorry for delay. I went through the PR and it looks fine. Please try one more rebase and I will merge it as soon as possible.

[StevenYGui]

Hello @StevenYGui and sorry for delay. I went through the PR and it looks fine. Please try one more rebase and I will merge it as soon as possible.

Thanks @vojtapolasek, I have rebased.

[vojtapolasek]

/packit retest-failed

[vojtapolasek]

Hello @StevenYGui and I am sorry for even more inconvenience... but I will need one more rebase.
We have just landed a big change related to prodtypes. To put it simple, we stopped using the "prodtype" key to signify which product the rule belongs to and we infer this only from its presence in a profile.
This makes it necessary to rebase again.
But, it will make the PR much smaller because you will not need to add openeuler prodtype to each rule.
Here is the discussion within the issue to get more context.
#11382

[StevenYGui]

Hello @StevenYGui and I am sorry for even more inconvenience... but I will need one more rebase. We have just landed a big change related to prodtypes. To put it simple, we stopped using the "prodtype" key to signify which product the rule belongs to and we infer this only from its presence in a profile. This makes it necessary to rebase again. But, it will make the PR much smaller because you will not need to add openeuler prodtype to each rule. Here is the discussion within the issue to get more context. #11382

@vojtapolasek , you're welcome. I think the modification of prodtype is a friendly modification that can be convenient for developers. I've rebaseed it. Please check it again. Thank you.

[codeclimate]

Code Climate has analyzed commit 4dcdd6e and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 58.3% (0.0% change).

View more on Code Climate.

[vojtapolasek]

Thank you, looks good now. Merging.

[StevenYGui]

Thank you, looks good now. Merging.

Thank you very much. I will continue to contribute to the community.