Bug 1857179

Hello, thank you for the report. Are you aware of more rules which are behaving in this way?

Hi,
I am aware of this one:

  - name: Modify the System Message of the Day Banner - remove incorrect banner
      file:
        state: absent
        path: /etc/motd
      tags:
        - banner_etc_motd
        - medium_severity
        - unknown_strategy
        - low_complexity
        - medium_disruption
        - no_reboot_needed
        - CCE-83496-0

    - name: Modify the System Message of the Day Banner - add correct banner
      lineinfile:
        dest: /etc/motd
        line: '{{ login_banner_text | regex_replace("^\^(.*)\$$", "\1") | regex_replace("^\((.*)\|.*\)$",
          "\1") | regex_replace("\[\\s\\n\]\+"," ") | regex_replace("\(\?:\[\\n\]\+\|\(\?:\\\\n\)\+\)",
          "\n") | regex_replace("\\", "") | wordwrap() }}'
        create: true
      tags:
        - banner_etc_motd
        - medium_severity
        - unknown_strategy
        - low_complexity
        - medium_disruption
        - no_reboot_needed
        - CCE-83496-0


I am not sure if the situation is similar with other rules. I briefly looked with other rules within a customized file for CIS, I did not see.
Having said that CIS has by default around 201 rules, and I saw over 1000+ rules in scap-workbench for all profiles.

So it is possible that it is similar on other rules.

Cheers,

For banner_etc_issue this, this commit https://github.com/ComplianceAsCode/content/commit/556018017f provides context why the Ansible remediation is written as it is.

Hello Jean, could you please react to Yuuma's comment?

Generally, Ansible is not powerful enough to enable us to write an idiomatic idempotent snippet. In this case, trailing blank lines could cause problems.

I guess that we could attempt to complicate the Ansible code to first perform a more thorough Ansible "scan", and erase the file iff this "scan" tells us that the file needs to be replaced. Or we can generate the correct file, and replace the original one iff the two differ.
In any case, could you please create a customer case for that if it is not a cosmetic issue?

Hi there,
Yes the issue was observed by the customer expert at SIX Group, and it's not a cosmetic issue.
I think to some extend that would impact every customers who are using a file integrity manager because it will trigger a notification that the file is no longer the same.
It looks that complicating the code by making a new file would result in the same situation?

Cheers,

Maybe the "slurp" module could be used to improve the Ansible remediation.
https://docs.ansible.com/ansible/latest/modules/slurp_module.html

Before removing the file, it could read the contents of the file with "slurp" and compare to the desired banner, there may be issues with newlines though. Testing needed.

If I understand it correctly, if the file is changed in place, then the customer's problem is solved, right? In this case, we can firstly clear the file and then put there the right content:
- name: clear the file
  lineinfile:
    path: /etc/issue
    regexp: '^.*$'
    state: absent
Is the customer willing to test it? Or can we test it so that we know that it won't trigger alarm on their file integrity manager?

(In reply to Matěj Týč from comment #4)
> Hello Jean, could you please react to Yuuma's comment?
> 
> Generally, Ansible is not powerful enough to enable us to write an idiomatic
> idempotent snippet. In this case, trailing blank lines could cause problems.
> 
> I guess that we could attempt to complicate the Ansible code to first
> perform a more thorough Ansible "scan", and erase the file iff this "scan"
> tells us that the file needs to be replaced. Or we can generate the correct
> file, and replace the original one iff the two differ.
> In any case, could you please create a customer case for that if it is not a
> cosmetic issue?

I like your statement: Ansible is not powerful

Seriously, no file should be touched when it already complies with the requirements.
I would go for your second proposal, create the expected content in a temporary file and update the original file only when it differs

(In reply to Vojtech Polasek from comment #7)
> If I understand it correctly, if the file is changed in place, then the
> customer's problem is solved, right? In this case, we can firstly clear the
> file and then put there the right content:
> - name: clear the file
>   lineinfile:
>     path: /etc/issue
>     regexp: '^.*$'
>     state: absent
> Is the customer willing to test it? Or can we test it so that we know that
> it won't trigger alarm on their file integrity manager?

Hi,
I'm the customer
I can test it and report if the current configuration of the File Integrity Monitor will tolerate a change of the Last Modified Date.

As stated above, the claim must be: no file is touched if not necessary

Patch for this bug sent to upstream:
https://github.com/ComplianceAsCode/content/pull/7228

The logic was changed to use the "copy" module instead of the combination of "file" and "lineinfile".
The copy module[1], with the "content" parameter, check the existing content first and only update the file if the existing content doesn't match the desired content.

By the way, I checked all the project and didn't find more similar occurrences besides the /etc/motd and /etc/issue.


[1] https://docs.ansible.com/ansible/latest/collections/ansible/builtin/copy_module.html

Upstream PR with the test: https://github.com/ComplianceAsCode/content/pull/7376

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (scap-security-guide bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4265