What is correct tag for rules 1.1.[3-7].1?

[boris-stojnev]

Question
I'm not sure if this is a bug or not. What is correct behavior? Should tasks in CIS mentioned below be tagged with level1 or level2?
Can run tag be specified with Audit, because Audit is reporting failed tasks for level2, when CIS is only run against level1?

In RHEL8-CIS several tasks with tag level1-server will be skipped while running with tag level1-server due to condition not true.

• 1.1.3.2, 1.1.3.3, 1.1.3.4 are marked with level1 tag and will be skipped, because 1.1.3.1 is marked as level2.
• 1.1.4.2, 1.1.4.3, 1.1.4.4 are marked with level1 tag and will be skipped, because 1.1.4.1 is marked as level2.
• 1.1.5.2, 1.1.5.3, 1.1.5.4 are marked with level1 tag and will be skipped, because 1.1.5.1 is marked as level2.
• 1.1.6.2, 1.1.6.3, 1.1.6.4 are marked with level1 tag and will be skipped, because 1.1.6.1 is marked as level2.
• 1.1.7.2, 1.1.7.3, 1.1.7.4, 1.1.7.5 are marked with level1 tag and will be skipped, because 1.1.7.1 is marked as level2.

Environment (please complete the following information):

• Ansible Version: 2.13.7
• Host Python Version: /
• Ansible Server Python Version: 3.8.10
• Additional Details:

[georgenalen]

Hi @boris-stojnev,
So I will tackle your questions in two parts. Part 1 is the first with tagging them as level1 or level2. Can you elaborate on that question a bit more? Currently they are tagged with the full level designation they are assigned in the benchmark. The reason for the whole name, for example level1-server vs just level1, is that some controls are level1-server and level2-workstation. So for consistency and accuracy we keep the whole name and all of the level settings tagged as they are called out in the benchmark.

The second question, can the run tag be specified with the audit? This is a harder problem to solve but we do have something that should help with this. In the defaults/main.yml you have the two variables rhel8cis_level_1 and rhel8cis_level_2 that are intended to help with this. These variables don't tie into any of the remediation tasks (Ansible role tasks), but what they are used for is toggling the built-in audit tasks. When you run the audit from the remediation role (Ansible role) there is a task that copies all of the variables you have set in Ansible to be variables in the audit. So if you disabled section2 via an extra var using the rhel8cis_section2 variable that will also disable the checks for section2 in the audit. This is how the rhel8cis_level_1 and rhel8cis_level_2 toggles works, using a variable to help set the audit settings. Since the Ansible run/skip tags can't be passed along to the audit tool, these two variables in defaults/main.yml was implemented to help with that. Let me know if that answers the question. it's a bit of a confusing issue/situation so the explanation probably is a bit confusing.

-George

[boris-stojnev]

@georgenalen thanks for such a quick answer.

Ah, sorry for the confusion here. Everywhere I wrote level1 I meant level1-server, and everywhere I wrote level2 I meant level2-server. It was just a slip of the tongue.

To be more precise with an example, I’m running with tag level1-server, but tasks 1.1.3.2, 1.1.3.3, 1.1.3.4 are skipped, because var_mount_present is defined as false in the when statement and the whole condition will be false. The var_mount_present it’s not defined only because the task 1.1.3.1 is marked with level2-server and will not be run with level1-server run tag.

So the question here is, should we mark 1.1.3.1 with level1-server as well, or should we change the condition statement in 1.1.3.2, 1.1.3.3, 1.1.3.4. All of this can be said for other tasks mentioned in my first post.

For the second question, yes I understand and I’m using

      rhel8cis_level_1: true
      rhel8cis_level_2: false

1.1.7.4 and 1.1.7.5 are marked with

   meta:
     server: 2
     workstation: 2

in the Audit, but I’m seeing them in the audit post scan as failed. Maybe this is going to we fixed with the first question resolving.

[georgenalen]

@boris-stojnev
Aaaahhhhh I see the issue. We try to avoid variables that is created through a register being used in a control outside of itself. In this case the var that is created in 1.1.3.1 (and the others that are similar) is being used in the 1.1.3.2-4. That is an issue and I am working on the fix for that. That is a good catch on that one. I can see all of those tasks have the same issue.

Once I get the changes for the problem with the variable sorted I will circle back to the audit side. Thanks for getting back so quick.

-George

[georgenalen]

I have the fixes in for the first set of questions, I'll work on merging that into devel by tomorrow. The other question about the audit is an issue with the audit itself. The way those checks are written are as if they are all level 1, however they are a mix so the "if" usage with that level 1/2 variable needs to be updated to address that. So I think the issues here are resolved, I will work on getting those addressed on the audit side.

-George

[boris-stojnev]

Thank you sir. Looks good.

Regarding Audit, maybe it’s better to open a separate ticket. Just for the sake of conversation, let me post here.
There are two issues regarding 1.1.7.4 and 1.1.7.5. First thing first, quotaon has to be installed on the host, and second there is typo error in cis_1.1.7.1_5.yml, missing quotes on grep regex
exec: quotaon -p /home | grep -E '(user|group)'

One more thing, for enhancement, because you didn’t predict that someone may put a label on partitions, so they will not end with ')' in mount -l command output :)

   {{ if .Vars.rhel8cis_rule_1_1_7_4 }}
   - '/.*\/home .*usrquota.*\)$/'
   {{ end }}
   {{ if .Vars.rhel8cis_rule_1_1_7_5 }}
   - '/.*\/home .*grpquota.*\)$/'

[uk-bolly]

hi @boris-stojnev

Thank you again for this issue, i believe that these have now been addressed in both this repo and the audit repo. They have both had releases against them.
I will close this issue, please feel free to reopen or open an new issues should you come across anything that is not quite right.

many thanks

uk-bolly