You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the Issue
There seems to be a logic flaw when detecting system accounts. The condition checks if the threshold min_int_uid is smaller than the user id of user accounts, instead of checking if the user id is smaller than min_int_uid.
Let's assume a user has the uid 1001 and a group named after the user with the group id 1001 and is therefore considered not a system account. In the tasks 5.6.2 the min_int_uid is checked if it is smaller than the user group id. Since 1000 is smaller than 1001 the user account is set to no login and locked.
- name: "5.6.2 | Ensure system accounts are secured | Set nologin"
user:
name: "{{ item.id }}"
shell: /usr/sbin/nologin
with_items:
- "{{ rhel9cis_passwd }}"
when:
- item.id != "root"
- item.id != "sync"
- item.id != "shutdown"
- item.id != "halt"
- item.id != "nfsnobody"
- min_int_uid | int < item.gid
- item.shell != " /bin/false"
- item.shell != " /usr/sbin/nologin"
loop_control:
label: "{{ item.id }}"
- name: "5.6.2 | PATCH | Ensure system accounts are secured | Lock accounts"
user:
name: "{{ item.id }}"
password_lock: true
with_items:
- "{{ rhel9cis_passwd }}"
when:
- item.id != "halt"
- item.id != "shutdown"
- item.id != "sync"
- item.id != "root"
- item.id != "nfsnobody"
- min_int_uid | int < item.gid
- item.shell != " /bin/false"
- item.shell != " /usr/sbin/nologin"
loop_control:
label: "{{ item.id }}"
Further is the comparison of the group id (gid) instead of the user id (uid) to the min_int_uid intentional? I noticed that the comparison of the group id with min_int_uid is consistent with rhel8-cis and rhel7-cis.
@uk-bolly Further: is the comparison of the group id (gid) instead of the user id (uid) to the min_int_uid intentional? I noticed that the comparison of the group id with min_int_uid is consistent with rhel8-cis and rhel7-cis.
Describe the Issue
There seems to be a logic flaw when detecting system accounts. The condition checks if the threshold
min_int_uid
is smaller than the user id of user accounts, instead of checking if the user id is smaller thanmin_int_uid
.Let's assume a user has the uid 1001 and a group named after the user with the group id 1001 and is therefore considered not a system account. In the tasks 5.6.2 the
min_int_uid
is checked if it is smaller than the user group id. Since 1000 is smaller than 1001 the user account is set to no login and locked.RHEL9-CIS/tasks/section_5/cis_5.6.x.yml
Lines 5 to 39 in d5cce24
Further is the comparison of the group id (
gid
) instead of the user id (uid
) to themin_int_uid
intentional? I noticed that the comparison of the group id withmin_int_uid
is consistent with rhel8-cis and rhel7-cis.https://github.com/ansible-lockdown/RHEL8-CIS/blob/33d4c643cbf8c22f6f1ed784e7c70e479630685e/tasks/section_5/cis_5.6.x.yml#L16
https://github.com/ansible-lockdown/RHEL7-CIS/blob/90f3d9a5fecebb75e16afe32ba096bf7817cd034/tasks/section_5/cis_5.5.x.yml#L17
Expected Behavior
Only accounts with the uid smaller than min_int_uid are locked.
Actual Behavior
All accounts with the uid bigger than min_int_uid are locked.
Control(s) Affected
5.6.2
Environment (please complete the following information):
Additional Notes
Possible Solution
Change the conditional from
min_int_uid | int < item.gid
toitem.gid < min_int_uid | int
.The text was updated successfully, but these errors were encountered: