Hello Ryan, this behaviour is default on Ansible, and trying to workaround it would be against the spirit of it. What you perceive might be issue in particular rule of the ansible playbooks. And that's truly something we will look into.

I will close this one as not a bug, but please feel free to report any unexpected remediation failures as separate bugs.

Marek, I understand that it is the default behavior on Ansible. But my concern is that in the current iteration the playbooks are nearly useless compared to just using the --remediate flag because as soon as the playbook hits any issue at all it completely exits. 

I'm not sure what the solution is, but I'm curious on the thinking for even leaving this in if as soon we we hit any errors for a missing file, etc. it exits. This would exponentially increase the time to remediate a system. I'm also concerned that any time someone tries to use Ansible remediations they're going to realize how bad the actual usage is in comparison to the other automated options available in openscap and then they're going to open a case with support for it.

I'm going to side with Ryan on this one and request we take a look at the playbook template behaviour. From his example:

<snip>
TASK [Ensure group owner 0 on /etc/cron.allow] **********************************************
failed: [localhost] (item=/etc/cron.allow) => {"changed": false, "item": "/etc/cron.allow", "msg": "file (/etc/cron.allow) is absent, cannot continue", "path": "/etc/cron.allow", "state": "absent"}
...ignoring

TASK [Ensure owner 0 on /etc/cron.allow] ****************************************************
failed: [localhost] (item=/etc/cron.allow) => {"changed": false, "item": "/etc/cron.allow", "msg": "file (/etc/cron.allow) is absent, cannot continue", "path": "/etc/cron.allow", "state": "absent"}
	to retry, use: --limit @/root/disatest1.retry
<snip>

The first entry is ignoring the error because the file is absent. The second one is not ignoring the failure and continuing on. There are a LARGE number of strategies available in Ansible to avoid these types of issues when writing playbooks, and I would expect any generated playbooks to use similar strategies in non-fatal error conditions.

For example - From a generated playbook:

    - name: Ensure owner 0 on /etc/cron.allow
      file:
        path: "{{ item }}"
        owner: 0
      with_items:
        - /etc/cron.allow
      tags:
        - file_owner_cron_allow
        - medium_severity
        - configure_strategy
        - low_complexity
        - low_disruption
        - CCE-80378-3
        - NIST-800-53-AC-6
        - DISA-STIG-RHEL-07-021110

This results in:

    # ansible-playbook -c local -i localhost, --tag file_owner_cron_allow disatest1.yml

    PLAY [all] *****************************************************************************************
 
    TASK [Gathering Facts] *****************************************************************************
    ok: [localhost]
 
    TASK [Ensure owner 0 on /etc/cron.allow] ***********************************************************
    failed: [localhost] (item=/etc/cron.allow) => {"changed": false, "item": "/etc/cron.allow", "msg": "file (/etc/cron.allow) is absent, cannot continue", "path": "/etc/cron.allow", "state": "absent"}
            to retry, use: --limit @/home/vagrant/disatest1.retry
 
    PLAY RECAP *****************************************************************************************
    localhost                  : ok=1    changed=0    unreachable=0    failed=1

Versus:

    - name: Ensure group owner 0 on /etc/cron.allow
      file:
        path: "{{ item }}"
        group: 0
      with_items:
        - /etc/cron.allow
      tags:
        - file_groupowner_cron_allow
        - medium_severity
        - configure_strategy
        - low_complexity
        - low_disruption
        - CCE-80379-1
        - NIST-800-53-AC-6
        - DISA-STIG-RHEL-07-021120
      ignore_errors: yes

Results:

    # ansible-playbook -c local -i localhost, --tag file_owner_cron_allow disatest1.yml

    PLAY [all] *****************************************************************************************

    TASK [Gathering Facts] *****************************************************************************
    ok: [localhost]

    TASK [Ensure owner 0 on /etc/cron.allow] ***********************************************************
    failed: [localhost] (item=/etc/cron.allow) => {"changed": false, "item": "/etc/cron.allow", "msg": "file (/etc/cron.allow) is absent, cannot continue", "path": "/etc/cron.allow", "state": "absent"}
    ...ignoring

    TASK [XCCDF Value var_sssd_ldap_tls_ca_dir] ********************************************************
    ok: [localhost]

    TASK [XCCDF Value sshd_approved_macs] **************************************************************
    ok: [localhost]

    <snip>

This can be even more gracefully avoided with:

    - name: Check to see if /etc/cron.allow exists
      stat:
        path: "/etc/cron.allow"
      tags:
        - file_owner_cron_allow
      register: cron_allow

    - name: Ensure owner 0 on /etc/cron.allow
      file:
        path: "{{ item }}"
        owner: 0
      with_items:
        - /etc/cron.allow
      tags:
        - file_owner_cron_allow
        - medium_severity
        - configure_strategy
        - low_complexity
        - low_disruption
        - CCE-80378-3
        - NIST-800-53-AC-6
        - DISA-STIG-RHEL-07-021110
      when: cron_allow.stat.exists == True and cron_allow.stat.isreg == True

Results:

    # ansible-playbook -c local -i localhost, --tag file_owner_cron_allow disatest1.yml | head -25

    PLAY [all] *****************************************************************************************

    TASK [Gathering Facts] *****************************************************************************
    ok: [localhost]

    TASK [Check to see if /etc/cron.allow exists] ******************************************************
    ok: [localhost]

    TASK [Ensure owner 0 on /etc/cron.allow] ***********************************************************
    skipping: [localhost] => (item=/etc/cron.allow)

    TASK [XCCDF Value var_sssd_ldap_tls_ca_dir] ********************************************************
    ok: [localhost]

    TASK [XCCDF Value sshd_approved_macs] **************************************************************
    ok: [localhost]

    TASK [XCCDF Value sshd_idle_timeout_value] *********************************************************
    ok: [localhost]

    TASK [XCCDF Value inactivity_timeout_value] ********************************************************
    ok: [localhost]

    TASK [XCCDF Value rsyslog_remote_loghost_address] **************************************************
    <snip>

If we are going to go to the trouble of creating Ansible playbooks as a remediation method, we should make sure that the results are functional...

- Kyle Walker

The following patches fix errors from tasks in OSPP profile
- https://github.com/ComplianceAsCode/content/pull/4041
- https://github.com/ComplianceAsCode/content/pull/4036

And following patches fix errors in tasks not selected in any profile:
- https://github.com/ComplianceAsCode/content/pull/4054
- https://github.com/ComplianceAsCode/content/pull/4109
- https://github.com/ComplianceAsCode/content/pull/4198

The primary issue here is that certain modules don't account for the possibility of files missing. It only expects that it exists, even though that isn't a requirement of the guideline itself. 

For example, if you don't have GNOME configured, it will fail at checking or disabling GNOME if you don't have it installed. One method would be to disable that particular security guideline, but for an enterprise solution (where all/some/none of hosts could have that file), you'd want to cover the gap to account for any servers with $FILE, so the best method for handling would be to perform an audit function prior to executing the task if that security guideline is deemed applicable by their AO.

- Josh

Hello Josh,

That is what most of the Ansible remediations should be doing now.
If a file that should be configured according to a rule is not present, we skip the task that would configure the file.

Are you facing issues with Ansible remediations related to GNOME?
Does it also happens with scap-security-guide-0.1.43-7.el7 ?

Thanks

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, 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-2019:2198