4.6.5 | PATCH | Ensure default user umask is 027 or more restrictive .. is missing check intentional?

[m-j-gardner]

Question
Hi,

I'm in the process of comparing what the CIS hardening script does vs what the AMAZON2023-CIS ansible-lockdown playbook does against an AWS AL2023 EC2 instance by running the playbook, rebooting the host, running the script against it and then having a look at what the script remediates i.e. find stuff that the playbook hasn't done. I'm only running the level1 tasks (it's to convince those upstairs to use the playbook rather than script).

The script appears to be performing an additional check/remediation in "4.6.5 | PATCH | Ensure default user umask is 027 or more restrictive" for some /etc/pam.d files (see output below).

Has this been omitted from the playbook on purpose?

Thanks.

Environment:

• Ansible Version: 2.15.11
• Host Python Version: Python 3.9.16
• Ansible Server Python Version: Python 3.9.16
• Additional Details: Host AWS AL2023 AMI = al2023-ami-2023.4.20240513.0-kernel-6.1-x86_64
• Referenced output:

**************************************************
- 21-Jun-2024 15:22:39
- Start Recommendation "4.6.5 - Ensure default user umask is 027 or more restrictive"
- Start check - Ensure default user shell timeout is configured
- UMASK configured correctly in /etc/login.defs
- USERGROUP_ENAB configured correctly in /etc/login.defs
- pam_umask.so NOT configured correctly in /etc/pam.d/password-auth
- UMASK configured correctly in:
/etc/bashrc:       umask 027
/etc/bashrc:       umask 027
- No less restrictive UMASK setting was found
- FAIL: UMASK is NOT set correctly
- End check - Ensure default user shell timeout is configured
- Start remediation - Ensure system accounts are secured
- Inserting pam_umask.so setting into /etc/pam.d/password-auth
- Inserting pam_umask.so setting into /etc/pam.d/system-auth
- End remediation - Ensure system accounts are secured
- Start check - Ensure default user shell timeout is configured
- UMASK configured correctly in /etc/login.defs
- USERGROUP_ENAB configured correctly in /etc/login.defs
- pam_umask.so configured correctly in /etc/pam.d/password-auth
- pam_umask.so configured correctly in /etc/pam.d/system-auth
- UMASK configured correctly in:
/etc/bashrc:       umask 027
/etc/bashrc:       umask 027
- No less restrictive UMASK setting was found
- PASS: UMASK is set correctly
- End check - Ensure default user shell timeout is configured
- Result - successfully remediated
- End Recommendation "4.6.5 - Ensure default user umask is 027 or more restrictive"
**************************************************

[uk-bolly]

hi @m-j-gardner

Thank you for the feedback and taking the time to raise this issue. Ive gone back and checked the documentation for the benchmark ( i have also checked the online version and this is still teh same with no ticket open for changes needed)

There appears to be two ways to set it.

• with pam_umask.so - using the pam modules
  or
• settings with systemwide scripts

excerpt

The default umask can be set to use the pam_umask module or in a System Wide Shell Configuration File. The user creating the directories or files has the discretion of changing the permissions via the chmod command, or choosing a different default umask by adding the umask command into a User Shell Configuration File, ( .bash_profile or .bashrc), in their home directory.

I am taking a look at this, we have chosen to carry out the control for the script and not via the pam.d configuration.

It appears like alot of scanners they don't always align with how the benchmark is written or sometimes alot more brittle checking for things in a certain way but other ways will work.
e.g.

value=1
value = 1

Happy to go through this further if required.

many thanks

uk-bolly

[uk-bolly]

hi @m-j-gardner

Thank you again for raising this issue, i hope that the answer gave you an understanding of our approach. We have had several more tickets raised with very similar over the last year all to do with the scanners not matching the written requirements or taking them too literally.
I will close this particular issue.

Many thanks

uk-bolly