-
Notifications
You must be signed in to change notification settings - Fork 778
Description
Description
When using os_hardening, the task - name: Remove shell for linux system accounts fails on coreos due to the system accounts extracted earlier from the getent password database in - name: Extract system accounts from local user database not existing in the /etc/passwd file.
In order to make the task pass, I defined os_ignore_users with a list of accounts extracted from the error json code that listed the accounts not found in /etc/passwd.
I then reran the os_hardening role, but when it reached - name: Remove shell for linux system accounts, the task failed because now system_users was undefined.
I presume I could define system_users, and leave it empty, but I suspect it would be better to add a conditional when system_users is defined (and possibly a check that it is non-empty) to the two tasks that use system_users, which are:
Remove shell for linux system accounts and
Lock passwords from linux system accounts
Reproduction steps
... - hosts: "{{ hostvars['localhost']['remote_ip'] }}" gather_facts: true remote_user: core become: yes become_method: sudo roles: - role: devsec.hardening.os_hardening vars: os_auditd_enabled: false os_immutable_fs: true os_ignore_users: - os_ignore_users - 'adm' - 'avahi-autoipd' - 'bin' - 'ceph' - 'chrony' - 'cockpit-ws' - 'daemon' - 'dbus' - 'dockerroot' - 'etcd' - 'ftp' - 'games' - 'kube' - 'lp' - 'mail' - 'nobody' - 'operator' - 'polkitd' - 'rpc' - 'rpcuser' - 'sshd' - 'sssd' - 'systemd-bus-proxy' - 'systemd-network' - 'systemd-resolve' - 'systemd-timesync' - 'tcpdump' - 'tss' - 'clevis' - 'dnsmasq' - 'zincati' - 'systemd-coredump' - 'systemd-oom' - 'usbmuxd'
Current Behavior
...
TASK [devsec.hardening.os_hardening : Remove shell for linux system accounts] *********************************************************
fatal: [192.168.1.134]: FAILED! => {"msg": "'system_users' is undefined"}
Expected Behavior
...
For the os_hardening role to complete successfully.
OS / Environment
Provide all relevant information below, e.g. target OS versions, network device firmware, etc.
coreos on raspberry pi running fedora 41
Ansible Version
ansible [core 2.18.3] config file = /var/home/james/src/motioncore/ansible.cfg configured module search path = ['/var/home/james/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /var/home/james/src/motioncore/.motioncore_venv/lib64/python3.13/site-packages/ansible ansible collection location = /var/home/james/.ansible/collections:/usr/share/ansible/collections executable location = /var/home/james/src/motioncore/.motioncore_venv/bin/ansible python version = 3.13.2 (main, Feb 4 2025, 00:00:00) [GCC 14.2.1 20250110 (Red Hat 14.2.1-7)] (/var/home/james/src/motioncore/.motioncore_venv/bin/python) jinja version = 3.1.6 libyaml = True
Collection Version
Paste version of the collection. This will be automatically formatted into code, so no need for backticks.
10.3.0Additional information
...