Describe the Issue
There are some rules that do not have the correct keywords or characters inside their titles.

Expected Behavior
All titles of rules should be written correctly in the appropriate manners.

Actual Behavior
There are rules that are missing keywords such as "PATCH" or characters such as "|".

Control(s) Affected

• control 1.3.3
• control 4.2.1
• control 4.6.2
• control 6.2.4
  Environment (please complete the following information):
• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The solution will be provided in a PR.

Describe the Issue
We have use the CIS hardening of amazon linux 2023 and build a new AMI.
With this AMI we have created a instance however instance is unable to connect ssm agent.

We have received below error
[ 14.119919] hibinit-agent[1747]: OSError: [Errno 101] Network is unreachable

Could you please suggest on it.

Expected Behavior
A clear and concise description of what you expected to happen.

Actual Behavior
A clear and concise description of what's happening.

Control(s) Affected
What controls are being affected by the issue

Environment (please complete the following information):

• branch being used: [e.g. devel]
• Ansible Version: [e.g. 2.10]
• Host Python Version: [e.g. Python 3.7.6]
• Ansible Server Python Version: [e.g. Python 3.7.6]
• Additional Details:

Additional Notes
Anything additional goes here

Possible Solution
Enter a suggested fix here

Describe the Issue
Running on minimal version so I ran the following to fix.

yum install gnupg2 --allowerasing -y

Script is failing on CIS 1.2.1
- name: "1.2.1 | AUDIT | Ensure GPG keys are configured | Query found keys"
ansible.builtin.shell: 'rpm -q --queryformat "%{PACKAGER} %{VERSION}\n" {{ os_gpg_key_pubkey_name }} | grep "{{ os_gpg_key_pubkey_content }}"'
changed_when: false
failed_when: false
register: os_gpg_key_check
when: os_installed_pub_keys.rc == 0

Expected Behavior
This should be mark as correct since the newest version is installed.

Actual Behavior
It is marked as failed. This was working before, I suspect Amazon changed the key signature.

rpm -q --queryformat "%{PACKAGER} %{VERSION}\n" gpg-pubkey-d832c631-63977702
package gpg-pubkey-d832c631-63977702 is not installed

I ran with another key.

rpm -q --queryformat "%{PACKAGER} %{VERSION}\n" gpg-pubkey-d832c631-63920d79
Amazon Linux [email protected] d832c631

Control(s) Affected
What controls are being affected by the issue

Environment (please complete the following information):

• branch being used: master
• Ansible Version: ansible [core 2.15.5]
• Host Python Version: 3.9.16
• Ansible Server Python Version: 3.9.16
• Additional Details: Ec2 instance

Additional Notes
Anything additional goes here

Possible Solution
Change the query to do gpg-pubkey instead of a specific number
rpm -q --queryformat "%{PACKAGER} %{VERSION}\n" gpg-pubkey
Amazon Linux [email protected] d832c631

Describe the Issue
The wrong file is getting edited for the implementation of this control.

Expected Behavior
At the "Remediation" section of this rule CIS states that one should Add or edit server or pool lines to file ending in .conf in the /etc/chrony.d as appropriate.

Actual Behavior
The task for this rule is trying to edit the configuration file from the "/etc" directory, which is close to, but not quite what CIS wants from this rule.

Control(s) Affected
2.1.2 Ensure chrony is configured

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
This is a quick fix by simply modifying the existing path from /etc/chrony.conf to /etc/chrony.d/chrony.conf. This fix will be provided in a PR.

Feature Request or Enhancement

• Enhancement [X]

Summary of Request
The pipeline-testing and local-testing parts of README.md list a few different ansible-core/Python combinations that the ansible-lockdown/AMAZON2023-CIS is tested with.

We added a packaged ansible-core to Amazon Linux 2023 in the 2023.2.20230920 release. As per the full package list, this is currently ansible-core version 2.15.3-1.amzn2023.0.1, which works with the system python, which is 3.9.

Seeing as this role is likely only going to be run on Amazon Linux 2023, the testing matrix should likely include this exact combination of ansible and python versions. This could probably be done in an AL2023 based container image with the associated packages being installed. I've not looked into the details of how you test the various bits, and am unsure if something requires booting an instance or not.

Describe Alternatives You've Considered

This feels like something we should package in Amazon Linux so that it can be easily available to all AL2023 users. I'll open a tracking issue in https://github.com/amazonlinux/amazon-linux-2023/issues and post the link here, but before doing that, I'd love to hear the opinion of the maintainers here on that as a possibility.

Suggested Code

none as of yet, happy to help if that's of assistance.

Question
keep getting this error - seems to happen when things moved from 2.7 to 3.x but also a pretty common error across multiple OS's.

amazon-ebs.instance: TASK [ansible-security/roles/AMAZON2-CIS : PRELIM | Section 1.6 | Ensure SELinux is installed] *** amazon-ebs.instance: fatal: [default]: FAILED! => {"changed": false, "failures": ["No package policycoreutils-python available."], "msg": "Failed to install some of the specified packages", "rc": 1, "results": []}

Environment (please complete the following information):

ansible --version ansible [core 2.15.4] config file = None configured module search path = ['/home/ec2-user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /home/ec2-user/workspace/AMI-Builder/ami-al2023-commercial/ansible-venv/lib/python3.9/site-packages/ansible ansible collection location = /home/ec2-user/.ansible/collections:/usr/share/ansible/collections executable location = /home/ec2-user/workspace/AMI-Builder/ami-al2023-commercial/ansible-venv/bin/ansible python version = 3.9.16 (main, Sep 29 2023, 03:37:09) [GCC 10.5.0 20230707 (Red Hat 10.5.0-1)] (/home/ec2-user/workspace/AMI-Builder/ami-al2023-commercial/ansible-venv/bin/python3.9) jinja version = 3.1.2 libyaml = True

Thoughts? Suggestions?

im running this via packer against an AL2023 AMI

here is the ansible setup im using
stage('Setup Python venv') { steps { echo "Setup venv and install ansible" sh ''' rm -rf /tmp/pip-install-* python3.9 -m venv ansible-venv source ansible-venv/bin/activate pip3.9 install ansible selinux ansible --version ''' }

here is the packer Resource

provisioner "ansible" { playbook_file = "./ami-al2023-play.yml" use_proxy = false extra_arguments = [ "--extra-vars", "ansible_python_interpreter=/usr/bin/python3 amzn2023cis_selinux_enforce=${var.amzn2023cis_selinux_enforce}" ] }

Describe the Issue
A clear and concise description of what the bug is.

Expected Behavior
normal execution of section 6 controls. Reviewing AL2 code there is a significant different in execution here.
Per normal Ansible expectations - there should be no need to install additional software to execute.

Actual Behavior
amazon-ebs.instance: TASK [ansible-security/roles/AMAZON2023-CIS : 6.1.12 | AUDIT | Ensure SUID and SGID files are reviewed | Alert SUID exist] *** amazon-ebs.instance: fatal: [default]: FAILED! => {"msg": "You need to install \"jmespath\" prior to running json_query filter"}

Control(s) Affected
CIS 6.1.12

Environment (please complete the following information):

 ansible --version 
ansible [core 2.15.4] 
    config file = None configured module search path = ['/home/ec2-user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] 
    ansible python module location = /home/ec2-user/workspace/AMI-Builder/ami-al2023-commercial/ansible-venv/lib/python3.9/site-packages/ansible 
   ansible collection location = /home/ec2-user/.ansible/collections:/usr/share/ansible/collections 
   executable location = /home/ec2-user/workspace/AMI-Builder/ami-al2023-commercial/ansible-venv/bin/ansible 
   python version = 3.9.16 (main, Sep 29 2023, 03:37:09) [GCC 10.5.0 20230707 (Red Hat 10.5.0-1)] (/home/ec2-user/workspace/AMI-Builder/ami-al2023-commercial/ansible-venv/bin/python3.9) 
  jinja version = 3.1.2 libyaml = True:

Branch

Additional Notes
I'm running this via packer against an AL2023 AMI

here is the ansible setup im using
stage('Setup Python venv') { steps { echo "Setup venv and install ansible" sh ''' rm -rf /tmp/pip-install-* python3.9 -m venv ansible-venv source ansible-venv/bin/activate pip3.9 install ansible selinux ansible --version ''' }

here is the packer Resource

provisioner "ansible" { playbook_file = "./ami-al2023-play.yml" use_proxy = false extra_arguments = [ "--extra-vars", "ansible_python_interpreter=/usr/bin/python3 amzn2023cis_selinux_enforce=${var.amzn2023cis_selinux_enforce}" ] }

Code Sinippet in Question

Line 316

      - name: "6.1.12 | AUDIT | Ensure SUID and SGID files are reviewed | Alert SGID exist"
        ansible.builtin.debug:
            msg: "Warning!! SGID set on items in {{ amzn2023cis_6_1_12_sgid_perms | json_query('results[*].stdout_lines[*]') | flatten }}"  # noqa    jinja[invalid]
        when: amzn2023cis_6_1_12_sgid_found

This Method for json parsing through out 6.1.x for debug messages will fail anytime invoked with out the additional package install.
msg: "Warning!! SGID set on items in {{ amzn2023cis_6_1_12_sgid_perms | json_query('results[*].stdout_lines[*]') | flatten }}" # noqa jinja[invalid]

Possible Solution
https://opensource.com/article/21/4/process-json-data-ansible
Section 3

Describe the Issue
As authconfig is not used anymore, the variable related to its installation should be removed!

Expected Behavior
There should be no variable named amzn2023cis_use_authconfig that conditions the installation of authconfig as the PRELIM task responsible for installing it, was removed in this PR.

Actual Behavior
The variable is still present.

Control(s) Affected
None.

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The solution will be provided in a PR.

Describe the Issue
The rule gets a "FAIL" result from CIS.

Expected Behavior
The task from this rule needs to make sure that the following files: /etc/login.defs, /etc/profile and /etc/bashrc contain UMASK 027 (for /etc/login.defs ) or umask 027 (for /etc/profile and /etc/bashrc).

Actual Behavior
Firstly, the regexp is not quite good and it does not edit the /etc/login.defs accordingly, adding a new line with UMASK 027 instead of editing the existing one.

Secondly, the way the task is written, it does not edit the /etc/bashrc file in a proper manner, only modifying one of the umask lines, not all of them.

Control(s) Affected
4.6.5 Ensure default user umask is 027 or more restrictive

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
First part of the solution would be to modify the regexp so that it will match the UMASK line in the /etc/login.defs file.
The second part would be to remove the /etc/bashrc file from being edited with the ansible.builtin.lineinfile module, and create another task that edits it with ansible.builtin.replace module (this would be the only manner in which we can ensure that all of the matching lines from this file will get edited properly).

By applying these modifications the files are edited according to CIS regulations and the rule passes!

This solution will be provided in a PR.

Describe the Issue
The "PRELIM | 4.3.3 | Find all sudoers files." has the wrong rule number written in the title, when conditional and tags.

Expected Behavior
As this rule creates a register that is only used in rule 4.3.4, only the number 4.3.4 should be mentioned in the when conditionals, the tags and the title.

Actual Behavior
The title of this preliminary task mentions number 4.3.3, and this wrong rule number is present in the when conditional and tags as well!

Control(s) Affected
Control 4.3.4

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The fix will be provided in a PR.

Describe the Issue
The value for the variable ClientAliveCountMax used in this rule, is faulty!

Expected Behavior
This rule ensures that SSH Idle Timeout Interval is configured.
In a nutshell, it is supposed to do this by editing the ClientAliveInterval and the ClientAliveCountMax variables.
CIS states that: "ClientAliveCountMax must be greater than zero in order to utilize the ability of SSH to drop idle connections."

Actual Behavior
The value for the ClientAliveCountMax variable is set to 0 in the /defaults/main.yml file.

Control(s) Affected
4.2.20 Ensure SSH Idle Timeout Interval is configured

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The solution is to edit the variable's value to a number greater than 0, such as 3. A following PR will contain the aforementioned fix!

Describe the Issue
The rule does not get executed because the command that retrieves the affected files and puts them in the amzn2023cis_6_1_10_perms_results register has no output.

Expected Behavior
The df --local -P | awk {'if (NR!=1) print $6'} | xargs -I '{}' find '{}' -xdev -type f -perm -0002 command from the first task related to control 6.1.10 should have been able to list the files that have world-writable permissions.

Actual Behavior
The command does not list any files, and the rule is considered as "Failed" from CIS's point of view.

Control(s) Affected
6.1.10 Ensure world writable files and directories are secured

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The command needs to be modified so that it detects all of the needed files. I will provide this in a PR!

Describe the Issue
Control 4.2.12 gets a "FAIL" result from CIS, because it does not comply to its requirements.

Expected Behavior
In its "Assessment" section CIS checks the compliance of this rule with a script and by looking at certain files. The files that are checked by CIS are the /etc/ssh/sshd_config file and all of the files ending in .conf from this path: /etc/ssh/sshd_config.d/. If all of these files are edited accordingly, the rule passes.

Actual Behavior
The rule edits only the file mentioned in the amzn2023cis_sshd_config_file variable. In this case it only edits the /etc/ssh/sshd_config file, leading to the failing of the rule!

Control(s) Affected
4.2.12 Ensure SSH X11 forwarding is disabled

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
The fix provided for this control can be applied to all of the rules from section 4.2.x, that have the same assessment method!

Possible Solution
As a solution, two preliminary tasks can be created. One that identifies .conf files from /etc/ssh/sshd_config.d/ and one that identifies the main configuration file. Both of these tasks are registering the files found. Based on these registers the rule's task can be rewritten to ensure that the needed line is added in all of the files checked by CIS.
This solution will be presented in a PR.

Describe the Issue
GRUB_CMDLINE_LINUX="audit=1 audit_backlog_limit=8192 pti=on page_poison=1 vsyscall=none" is a sample line.

Expected Behavior
Audit for the process prior to start of auditd should pass.

Actual Behavior
This is actually showing up as failed.

Control(s) Affected
What controls are being affected by the issue
CIS 5.2.1.2

Environment (please complete the following information):

• branch being used: [e.g. devel] devel
• Ansible Version: [e.g. 2.10] ansible [core 2.15.5]
• Host Python Version: [e.g. Python 3.7.6] 3.9.16
• Ansible Server Python Version: [e.g. Python 3.7.6] 3.9.16
• Additional Details:

Additional Notes
Anything additional goes here

Possible Solution
Use GRUB_CMDLINE_LINUX instead of GRUB_CMDLINE_LINUX_Default

Describe the Issue

The last tag created is named differently than the previous ones (no v prefix) :

• 1.1.0
• v1.0.0
• v0.9.0

when I try to install the role, it creates the following error:

% ansible-galaxy role install MindPointGroup.amazon2023_cis
Starting galaxy role install process
- downloading role 'amazon2023_cis', owned by MindPointGroup
[WARNING]: - MindPointGroup.amazon2023_cis was NOT installed successfully: Unable to compare role versions (v0.9.0, v1.0.0, 1.1.0) to determine the most recent version due to incompatible
version formats. Please contact the role author to resolve versioning conflicts, or specify an explicit role version to install.
ERROR! - you can use --ignore-errors to skip failed roles and finish processing the list.

Expected Behavior

consistent naming :)

Actual Behavior

naming differs

Control(s) Affected

What controls are being affected by the issue

Environment (please complete the following information):

• branch being used: galaxy
• Ansible Version: 2.16.5
• Host Python Version: 3.12
• Ansible Server Python Version: 3.12.3
• Additional Details:

Additional Notes

workaround is to specify the version : ansible-galaxy role install MindPointGroup.amazon2023_cis,1.1.0

Possible Solution

recreate the release on the same commit, but with v1.1.0 tag

Describe the Issue
Multiple task

• ""1.1.2.2 | PATCH | Ensure nodev option set on /tmp partition"
  "1.1.2.3 | PATCH | Ensure noexec option set on /tmp partition"
  "1.1.2.4 | PATCH | Ensure nosuid option set on /tmp partition"" that ensures different options are set on the /tmp partition via the systemd method, also has 1.1.2.1 rule number in the title, when conditional and tags!

Expected Behavior
Number 1.1.2.1 should not be present as there is already another task that is responsible for ensuring that rule 1.1.2.1 is executed.

Actual Behavior
1.1.2.1 is present.

Control(s) Affected
None, just a syntax issue.

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The solution will be provided in a PR.

Describe the Issue
The fail_msg alerts the user that they do not have a root password while having a rule enabled that requires said root password to be set. That rule's number is wrong "You have rule 5.6.6 enabled this requires that you have a root password set".

Expected Behavior
The rule number should be 4.6.6

Actual Behavior
Instead the number is 5.6.6

Control(s) Affected
None really, just a minor syntax mistake.

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The fix will be provided in a PR.

Feature Request or Enhancement

Documenting the variables of the role from defaults/main.yml in a more detailed and improved manner, might help users to carry modifications easier and understand the Ansible role better.

Summary of Request
I shall provide a PR with the necessary modifications for enhancing the documentation of the variables!

Describe Alternatives You've Considered
None

Suggested Code
The suggested code will be provided in a PR!

Describe the Issue
The implementation of this control lacks one of the things that CIS considers necessary for the rule to be compliant.

Expected Behavior
As stated in the "Remediation" section of this rule, CIS mentions that if the rpcbind package is required as a dependency, one should stop and mask both the rpcbind.service and rpcbind.socket systemd units.

Actual Behavior
At this moment the tasks are written to only stop and mask the rpcbind.socket, which leads to a "FAIL" result from CIS.

Control(s) Affected
2.2.17 Ensure rpcbind is not installed or the rpcbind services are masked

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The tasks for this control need to stop and mask the rpcbind.service as well as the rpcbind.socket. This solution will be provided in a PR.

Describe the Issue
If the auditd_conf_files register used in this task is empty or undefined then the task would fail.
Expected Behavior
The task should not fail even if the register is empty.

Actual Behavior
The task fails because of the order of execution in ansible fields. The first when conditional
when: - item.mode != '06(0|4)0'

is the one responsible for this, along with the loop: used in the task : loop: "{{ auditd_conf_files.files }}".

If one combines a when statement with a loop, Ansible processes the condition separately for each item. This is by design, so you can execute the task on some items in the loop and skip it on other items.

The documentation for Ansible provides a solution:

Control(s) Affected

• Control 5.2.4.5

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The fix will be provided in a PR.

Describe the Issue
amazon-ebs.al2023: TASK [harden-amazon-linux-2023 : 5.1.1.1 | PATCH | Ensure rsyslog installed] ***
amazon-ebs.al2023: fatal: [default]: FAILED! => {"changed": false, "failures": ["No package rsyslog available."], "msg": "Failed to install some of the specified packages", "rc": 1, "results": []}

This is the control:

• name: "5.1.1.1 | PATCH | Ensure rsyslog installed"
  ansible.builtin.package:
  name: rsyslog
  state: present
  when:
  - "'rsyslog' not in ansible_facts.packages"
  - amzn2023cis_rule_5_1_1_1
  tags:
  - level1-server
  - patch
  - rsyslog
  - rule_5.1.1.1
  - nist_sp800-53r5_AU-3
  - nist_sp800-53r5_AU-12
  - nist_sp800-53r5_SI-5

I am able to install package using dnf directly:

[root@ip-10-10-10-67 bin]# dnf install rsyslog
Last metadata expiration check: 2:47:23 ago on Wed Oct 25 11:09:38 2023.
Dependencies resolved.

Package Architecture Version Repository Size

Installing:
rsyslog x86_64 8.2204.0-3.amzn2023.0.4 amazonlinux 784 k
Installing dependencies:
libestr x86_64 0.1.11-1.amzn2023.0.2 amazonlinux 26 k
libfastjson x86_64 0.99.9-1.amzn2023.0.3 amazonlinux 39 k
Installing weak dependencies:
rsyslog-logrotate x86_64 8.2204.0-3.amzn2023.0.4 amazonlinux 10 k

Transaction Summary

Install 4 Packages

Total download size: 859 k
Installed size: 2.8 M
Is this ok [y/N]: y
Downloading Packages:
(1/4): libestr-0.1.11-1.amzn2023.0.2.x86_64.rpm 331 kB/s | 26 kB 00:00
(2/4): libfastjson-0.99.9-1.amzn2023.0.3.x86_64.rpm 364 kB/s | 39 kB 00:00
(3/4): rsyslog-logrotate-8.2204.0-3.amzn2023.0.4.x86_64.rpm 311 kB/s | 10 kB 00:00
(4/4): rsyslog-8.2204.0-3.amzn2023.0.4.x86_64.rpm 5.6 MB/s | 784 kB 00:00

Total 4.1 MB/s | 859 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : libestr-0.1.11-1.amzn2023.0.2.x86_64 1/4
Installing : libfastjson-0.99.9-1.amzn2023.0.3.x86_64 2/4
Installing : rsyslog-logrotate-8.2204.0-3.amzn2023.0.4.x86_64 3/4
Installing : rsyslog-8.2204.0-3.amzn2023.0.4.x86_64 4/4
Running scriptlet: rsyslog-8.2204.0-3.amzn2023.0.4.x86_64 4/4
Created symlink /etc/systemd/system/multi-user.target.wants/rsyslog.service → /usr/lib/systemd/system/rsyslog.service.

Verifying : rsyslog-8.2204.0-3.amzn2023.0.4.x86_64 1/4
Verifying : libfastjson-0.99.9-1.amzn2023.0.3.x86_64 2/4
Verifying : libestr-0.1.11-1.amzn2023.0.2.x86_64 3/4
Verifying : rsyslog-logrotate-8.2204.0-3.amzn2023.0.4.x86_64 4/4

Installed:
libestr-0.1.11-1.amzn2023.0.2.x86_64 libfastjson-0.99.9-1.amzn2023.0.3.x86_64 rsyslog-8.2204.0-3.amzn2023.0.4.x86_64 rsyslog-logrotate-8.2204.0-3.amzn2023.0.4.x86_64

Complete!

Describe the Issue
Control 6.1.12 has two different tasks one of which has nothing to do with Ensure SUID and SGID files are reviewed.

Expected Behavior
There should only be one task that implements the 6.1.12 control.

Actual Behavior
There is indeed only one task that does this, only that there is another task with the same number 6.1.12 that does something needed to be done for control 6.1.10. 6.1.12 | PATCH | Ensure sticky bit is set on all world-writable directories, the sticky bit needs to be set in control 6.1.10 not control 6.1.12!

Control(s) Affected
Control 6.1.10
Control 6.1.12

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The solution will be provided in a PR.

Describe the Issue
Some tasks do not have the same rule number in the title, when conditional and tags.

Expected Behavior
The same rule number should be present in all three categories.

Actual Behavior
Some rules present inconsistencies in this!

Control(s) Affected

• control 1.1.7.2, 1.1.7.3
• control 1.3.3
• control 4.1.3
• control 4.1.9

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
A fix will be provided within a PR.

Describe the Issue
After applying tasks for rule 1.4.1 to instance with secure boot (arm64) we have a broken /etc/fstab

Expected Behavior
Added permissions parameters to secureboot partition in /etc/fstab:

-  UUID=03D1-7AD6        /boot/efi       vfat    defaults,noatime,uid=0,gid=0,umask=0077,shortname=winnt,x-systemd.automount 0 2
+ UUID=03D1-7AD6        /boot/efi       vfat    defaults,umask=0027,fmask=0077,uid=0,gid=0 0 0

Actual Behavior
bad line for secure boot partition in /etc/fstab:

-  UUID=03D1-7AD6        /boot/efi       vfat    defaults,noatime,uid=0,gid=0,umask=0077,shortname=winnt,x-systemd.automount 0 2
+ <g>UUID=03D1-7AD6        /boot/efi       vfat    defaults,umask=0027,fmask=0077,uid=0,gid=0 0 0

Control(s) Affected
Instance switches to emergency boot mode after restart

Environment (please complete the following information):

• branch being used: devel
• Ansible Version: 2.15
• Host Python Version: Python 3.9.16
• Additional Details: Instance Arch: Aarch64

Describe the Issue
The "PRELIM | capture /etc/password variables" task has wrong tags.

Expected Behavior
This preliminary task should have had tags for rules that can make use of it.

Actual Behavior
Instead this task mentions in tags, rules that are non-existent for the role (such as rule_5.5.2 rule_5.6.2) or rules that do not need this preliminary task to be executed for them (rule_6.2.9, rule_6.2.10, rule_6.2.11). This fact renders these tags to be irrelevant as well:
amzn2023cis_section5, amzn2023cis_section6.
Control(s) Affected
None, just a syntax mistake

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The fix will be provided in a PR.

Describe the Issue
All of the rules that make up section 1.6.1.x do not appear in the output of the role and are not getting executed!

Expected Behavior
If we take a look at the main.yml file from section 1, we can see that the "cis_1.6.1.x.yml" file is getting included by the ansible.builtin.include_tasks module, based on a when condition.

Actual Behavior
Even if the when condition is evaluated as true and the including of the tasks from "cis_1.6.1.x.yml" should be executed, no tasks from section 1.6.1.x are getting added to the role, nor executed in its output!

Control(s) Affected

• 1.6.1.1 Ensure SELinux is installed
• 1.6.1.2 Ensure SELinux is not disabled in bootloader configuration
• 1.6.1.3 Ensure SELinux policy is configured
• 1.6.1.4 Ensure the SELinux mode is not disabled
• 1.6.1.5 Ensure the SELinux mode is enforcing
• 1.6.1.6 Ensure no unconfined services exist
• 1.6.1.7 Ensure SETroubleshoot is not installed
• 1.6.1.8 Ensure the MCS Translation Service (mcstrans) is not installed

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Apart from the fix applied for the inclusion of tasks from section 1.6.1.x, the same fix is applied for task 1.9 (because it was using the same module)

Possible Solution
The ansible.builtin.include_tasks module seems to not be working properly. As a quick fix, this module can be discarded in favour of the ansible.builtin.import_tasks module. By using this modification, the rules are getting added to the role and therefore, executed!

This solution will be provided in a PR.

Describe the Issue
The "PRELIM | Install authconfig" task is not used anywhere.

Expected Behavior
All tasks that exist should serve a purpose for the role.

Actual Behavior
The task "PRELIM | Install authconfig" is not used anywhere. First, I noticed the tags and when conditional, contained rule numbers that do not exist such as: rule_5.3.1, rule_5.3.2, rule_5.3.3. Then while searching I realised authconfig is not needed anywhere for the role to fulfil its purpose.

Control(s) Affected
None, the task always gets skipped anyway.

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
I will provide a PR that removes this task, as a solution!

Describe the Issue
In the main.yml file from section_5, cis_5.3.yml is imported twice.

Expected Behavior
The file that contains the tasks for control 5.3 should be imported only once in the main.yml file.

Actual Behavior
The file is imported twice.

Control(s) Affected
None really, just a syntax issue related to control 5.3.

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
A solution will be provided in a PR!

Describe the Issue
Thanks to the discovery of my colleague @ipruteanu-sie from here. I noticed that the same behavior is present on AL2023 as well.

Expected Behavior
The first three rules should be implemented via /etc/login.defs and via the chage tool as CIS suggests.

Actual Behavior
The rules are only implemented using /etc/login.defs.

Control(s) Affected

• Control 4.6.1.1
• Control 4.6.1.2
• Control 4.6.1.3

Environment (please complete the following information):

• branch being used: [e.g. devel]

Additional Notes
Anything additional goes here

Possible Solution
The solution will be provided in a PR.