Hi @rumch-se. 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.

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

@rumch-se , please take a look in the CI tests. A lot is failing. It might be related to the prodtype definition in the new rule, since it was set as dependency in another rule used by many products. This is my suspicious but needs to be better investigated.

Another point, I would suggest to not create the dependency relationship in this way. You could define a package platform in the ensure_logrotate_activated rule. It would make it simpler and aligned to other similar rules.

This datastream diff is auto generated by the check Compare DS/Generate Diff

New content has different text for rule 'xccdf_org.ssgproject.content_rule_package_logrotate_installed'.
--- xccdf_org.ssgproject.content_rule_package_logrotate_installed
+++ xccdf_org.ssgproject.content_rule_package_logrotate_installed
@@ -6,7 +6,7 @@
 logrotate is installed by default. The logrotate package can be installed with the following command:  $ sudo yum install logrotate
 
 [reference]:
-BP28(R43)
+BP28(R71)
 
 [reference]:
 NT12(R18)

New content has different text for rule 'xccdf_org.ssgproject.content_rule_ensure_logrotate_activated'.
--- xccdf_org.ssgproject.content_rule_ensure_logrotate_activated
+++ xccdf_org.ssgproject.content_rule_ensure_logrotate_activated
@@ -11,7 +11,7 @@
 daily
 
 [reference]:
-BP28(R43)
+BP28(R71)
 
 [reference]:
 NT12(R18)

OVAL for rule 'xccdf_org.ssgproject.content_rule_ensure_logrotate_activated' differs.
--- oval:ssg-ensure_logrotate_activated:def:1
+++ oval:ssg-ensure_logrotate_activated:def:1
@@ -1,6 +1,6 @@
 criteria AND
+extend_definition oval:ssg-package_logrotate_installed:def:1
 criterion oval:ssg-test_logrotate_conf_daily_setting:tst:1
 criterion oval:ssg-test_logrotate_conf_no_other_keyword:tst:1
 criteria OR
 criterion oval:ssg-test_cron_daily_logrotate_existence:tst:1
-extend_definition oval:ssg-timer_logrotate_enabled:def:1

bash remediation for rule 'xccdf_org.ssgproject.content_rule_ensure_logrotate_activated' differs.
--- xccdf_org.ssgproject.content_rule_ensure_logrotate_activated
+++ xccdf_org.ssgproject.content_rule_ensure_logrotate_activated
@@ -1,5 +1,5 @@
 # Remediation is applicable only in certain platforms
-if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ]; then
+if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && { rpm --quiet -q logrotate; }; then
 
 LOGROTATE_CONF_FILE="/etc/logrotate.conf"
 

ansible remediation for rule 'xccdf_org.ssgproject.content_rule_ensure_logrotate_activated' differs.
--- xccdf_org.ssgproject.content_rule_ensure_logrotate_activated
+++ xccdf_org.ssgproject.content_rule_ensure_logrotate_activated
@@ -1,10 +1,27 @@
+- name: Gather the package facts
+  package_facts:
+    manager: auto
+  tags:
+  - CCE-80794-1
+  - NIST-800-53-CM-6(a)
+  - PCI-DSS-Req-10.7
+  - PCI-DSSv4-10.5.1
+  - configure_strategy
+  - ensure_logrotate_activated
+  - low_complexity
+  - low_disruption
+  - medium_severity
+  - no_reboot_needed
+
 - name: Configure daily log rotation in /etc/logrotate.conf
   lineinfile:
     create: true
     dest: /etc/logrotate.conf
     regexp: ^daily$
     line: daily
-  when: ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+  when:
+  - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+  - '"logrotate" in ansible_facts.packages'
   tags:
   - CCE-80794-1
   - NIST-800-53-CM-6(a)
@@ -23,7 +40,9 @@
     dest: /etc/logrotate.conf
     regexp: ^[\s]*(weekly|monthly|yearly)$
     state: absent
-  when: ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+  when:
+  - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+  - '"logrotate" in ansible_facts.packages'
   tags:
   - CCE-80794-1
   - NIST-800-53-CM-6(a)
@@ -51,7 +70,9 @@
       path: /etc/cron.daily/logrotate
       line: /usr/sbin/logrotate /etc/logrotate.conf
       regexp: ^[\s]*/usr/sbin/logrotate[\s\S]*/etc/logrotate.conf$
-  when: ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+  when:
+  - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+  - '"logrotate" in ansible_facts.packages'
   tags:
   - CCE-80794-1
   - NIST-800-53-CM-6(a)

Platform has been changed for rule 'xccdf_org.ssgproject.content_rule_ensure_logrotate_activated'
--- xccdf_org.ssgproject.content_rule_ensure_logrotate_activated
+++ xccdf_org.ssgproject.content_rule_ensure_logrotate_activated
@@ -1 +1 @@
-
+oval:ssg-package_logrotate:def:1

xccdf_org.ssgproject.content_rule_timer_logrotate_enabled is missing in new datastream.

Hello @marcusburghardt

I will provide some additional details about this rule.

1.There is a dependency between the rule ensure_logrotate_activated and the rules package_logrotate_installed and timer_logrotate_enabled.
2.Both rules package_logrotate_installed and timer_logrotate_enabled must be executed before ensure_logrotate_activated
3.For some reason RedHat has CIS numbers in package_logrotate_installed and timer_logrotate_enabled but does not have CCE numbers in identifier sections
4.Usually when we use the old approach for rules definition in the profiles we put the rules in alphabetical order - but in this case ensure_logrotate_activated will be before the rules package_logrotate_installed and timer_logrotate_enabled - i.e. this will impact the order of execution of the rules during the remediation.
5. With the approach via control files we can set the order of the rules to be executed in the more logical way i.e. package_logrotate_installed, timer_logrotate_enabled and logrotate_activated

I did a new commit in which I removed prodtype: sle12,sle15 from the rules package_logrotate_installed and timer_logrotate_enabled, but you can see from it, that we have:

The following tests FAILED:
140 - missing-cces-rhel7 (Failed)
155 - missing-cces-rhel8 (Failed)
168 - missing-cces-rhel9 (Failed)

In this case we have something like a "egg and chicken paradox" - when we have prodtypes sle12,15 - we have errors, but when we don't have them we again have errors, because RedHat had not added CCE codes to 2 rules.

I think that some changes should be done on the RedHat site - this issue to be resolved, but I am not in the position to make these changes.

Have a nice day
Rumen

Hello @marcusburghardt

I will provide some additional details about this rule.

1.There is a dependency between the rule ensure_logrotate_activated and the rules package_logrotate_installed and timer_logrotate_enabled. 2.Both rules package_logrotate_installed and timer_logrotate_enabled must be executed before ensure_logrotate_activated 3.For some reason RedHat has CIS numbers in package_logrotate_installed and timer_logrotate_enabled but does not have CCE numbers in identifier sections 4.Usually when we use the old approach for rules definition in the profiles we put the rules in alphabetical order - but in this case ensure_logrotate_activated will be before the rules package_logrotate_installed and timer_logrotate_enabled - i.e. this will impact the order of execution of the rules during the remediation. 5. With the approach via control files we can set the order of the rules to be executed in the more logical way i.e. package_logrotate_installed, timer_logrotate_enabled and logrotate_activated

I did a new commit in which I removed prodtype: sle12,sle15 from the rules package_logrotate_installed and timer_logrotate_enabled, but you can see from it, that we have:

The following tests FAILED: 140 - missing-cces-rhel7 (Failed) 155 - missing-cces-rhel8 (Failed) 168 - missing-cces-rhel9 (Failed)

In this case we have something like a "egg and chicken paradox" - when we have prodtypes sle12,15 - we have errors, but when we don't have them we again have errors, because RedHat had not added CCE codes to 2 rules.

I think that some changes should be done on the RedHat site - this issue to be resolved, but I am not in the position to make these changes.

Have a nice day Rumen

@marcusburghardt @rumch-se check if this 086935e workaround for failing CCE tests is reasonable from your point of view

Hello @marcusburghardt
I will provide some additional details about this rule.
1.There is a dependency between the rule ensure_logrotate_activated and the rules package_logrotate_installed and timer_logrotate_enabled. 2.Both rules package_logrotate_installed and timer_logrotate_enabled must be executed before ensure_logrotate_activated 3.For some reason RedHat has CIS numbers in package_logrotate_installed and timer_logrotate_enabled but does not have CCE numbers in identifier sections 4.Usually when we use the old approach for rules definition in the profiles we put the rules in alphabetical order - but in this case ensure_logrotate_activated will be before the rules package_logrotate_installed and timer_logrotate_enabled - i.e. this will impact the order of execution of the rules during the remediation. 5. With the approach via control files we can set the order of the rules to be executed in the more logical way i.e. package_logrotate_installed, timer_logrotate_enabled and logrotate_activated
I did a new commit in which I removed prodtype: sle12,sle15 from the rules package_logrotate_installed and timer_logrotate_enabled, but you can see from it, that we have:
The following tests FAILED: 140 - missing-cces-rhel7 (Failed) 155 - missing-cces-rhel8 (Failed) 168 - missing-cces-rhel9 (Failed)
In this case we have something like a "egg and chicken paradox" - when we have prodtypes sle12,15 - we have errors, but when we don't have them we again have errors, because RedHat had not added CCE codes to 2 rules.
I think that some changes should be done on the RedHat site - this issue to be resolved, but I am not in the position to make these changes.
Have a nice day Rumen

@marcusburghardt @rumch-se check if this 086935e workaround for failing CCE tests is reasonable from your point of view

@teacup-on-rockingchair would work, but I just reviewed those rules and the CIS benchmarks for RHEL and we can make it simpler. The relevant requirement is manual in CIS and therefore we are not including these rules in CIS profiles for RHEL. However, it makes sense to make them available for tailoring files. So I'll quickly add CCEs to these rules and we can rebase this PR.

PR is sent: #10904

As soon as it is merged, you can rebase this PR and we should no longer have issues with CCEs.

There is one required test failing and the error seems legit:

TASK [Enable timer logrotate] **************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Could not find the requested service logrotate.timer: host"}

I will run some local tests to get more details.

Could not find the requested service logrotate.timer

That is strange why it attempts to run that task at the first place on centos. Maybe the problem is with my condition being {{% if 'sle' in product %}}, maybe I should convert it to {{% if product in ["sle15"] %}} ? what do you think ?

Could not find the requested service logrotate.timer

That is strange why it attempts to run that task at the first place on centos. Maybe the problem is with my condition being {{% if 'sle' in product %}}, maybe I should convert it to {{% if product in ["sle15"] %}} ? what do you think ?

I can't see any jinja2 condition in this PR.

The issue is caused when trying to remediate the timer_logrotate_enabled rule.
This rule was included in the ANSSI control file and consequently is used by RHEL / CentOS and other distros with an ANSSI profile. It is failing because there is no logrotate.timer unit in CS8. Checking the logrotate Upstream, it seems the logrotate.timer unit was introduced since the 3.15 release. In this case, we could include a version in the platform applicability. Could you confirm the logrotate version with logrotate.timer unit in sle12 and sle15, please?

Could not find the requested service logrotate.timer

That is strange why it attempts to run that task at the first place on centos. Maybe the problem is with my condition being {{% if 'sle' in product %}}, maybe I should convert it to {{% if product in ["sle15"] %}} ? what do you think ?

I can't see any jinja2 condition in this PR.

I thought that the error is in ./linux_os/guide/system/logging/log_rotation/ensure_logrotate_activated/ansible/shared.yml, where there is a a check if product is sle or not.

The issue is caused when trying to remediate the timer_logrotate_enabled rule. This rule was included in the ANSSI control file and consequently is used by RHEL / CentOS and other distros with an ANSSI profile. It is failing because there is no logrotate.timer unit in CS8. Checking the logrotate Upstream, it seems the logrotate.timer unit was introduced since the 3.15 release. In this case, we could include a version in the platform applicability. Could you confirm the logrotate version with logrotate.timer unit in sle12 and sle15, please?

For sure in SLE12-SP5 - we have the package version 3.11.0, and the timer defined, so putting a version 3.14 will make the rule there inapplicable, while it can be used.
Also it looks kind of dangerous to assume same package versions on different distros, if I understand correctly the suggested change, can we add also OS as platform limitation or do some extra code in the oval to report not applicable?

while it can be used

Ok. In this case the suggested update to the platform is not good.
Maybe for now we have to include the prodtype: sle12,sle15,rhel9 in this rule or even something like os_linux[rhel]>=9.0 and os_linux[sle] ...
Other products can be included after, on demand. What do you think?

while it can be used

Ok. In this case the suggested update to the platform is not good. Maybe for now we have to include the prodtype: sle12,sle15,rhel9 in this rule or even something like os_linux[rhel]>=9.0 and os_linux[sle] ... Other products can be included after, on demand. What do you think?

Added prodtype clause to the rule definition, and also jinja condition in the ensure_logrotate_activated oval, so the rule is applicable only when we have logrotate.timer definition. @ComplianceAsCode/oracle-maintainers , @ComplianceAsCode/ubuntu-maintainers , can you please review the last change and suggest products, which should be added to the prodtype clause?

Code Climate has analyzed commit be538b9 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 53.2% (0.0% change).

View more on Code Climate.