Security controls for user accounts on Linux systems are a crucial barrier to prevent unauthorized access.
Many of the STIG requirements for user account controls are already included in many Linux distributions or they can be applied without disruptions. However, some requirements can cause problems with user authentication without coordination.
Deployers should consider an authentication solution that uses centralized authentication, such as LDAP, Active Directory, or Kerberos, for the best security posture.
All of the tasks for these STIG requirements are included in
tasks/rhel7stig/accounts.yml
.
The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.
Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.
Deployers can enable all password quality requirements by setting the master
switch variable to yes
:
security_pwquality_apply_rules: yes
When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:
security_pwquality_require_uppercase: no
The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.
Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.
Deployers can enable all password quality requirements by setting the master
switch variable to yes
:
security_pwquality_apply_rules: yes
When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:
security_pwquality_require_lowercase: no
The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.
Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.
Deployers can enable all password quality requirements by setting the master
switch variable to yes
:
security_pwquality_apply_rules: yes
When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:
security_pwquality_require_numeric: no
The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.
Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.
Deployers can enable all password quality requirements by setting the master
switch variable to yes
:
security_pwquality_apply_rules: yes
When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:
security_pwquality_require_special: no
The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.
Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.
Deployers can enable all password quality requirements by setting the master
switch variable to yes
:
security_pwquality_apply_rules: yes
When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:
security_pwquality_require_characters_changed: no
The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.
Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.
Deployers can enable all password quality requirements by setting the master
switch variable to yes
:
security_pwquality_apply_rules: yes
When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:
security_pwquality_require_character_classes_changed: no
The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.
Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.
Deployers can enable all password quality requirements by setting the master
switch variable to yes
:
security_pwquality_apply_rules: yes
When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:
security_pwquality_limit_repeated_characters: no
The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.
Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.
Deployers can enable all password quality requirements by setting the master
switch variable to yes
:
security_pwquality_apply_rules: yes
When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:
security_pwquality_limit_repeated_character_classes: no
The PAM configuration file for password storage is checked to ensure that
sha512
is found on the pam_unix.so
line. If sha512
is not found,
a debug message is printed in the Ansible output.
The default password storage mechanism for Ubuntu 16.04, CentOS 7, openSUSE Leap,
SUSE Linux Enterprise 12 and Red Hat Enterprise Linux 7 is SHA512
and the tasks
in the security role ensure that the default is maintained.
Deployers can configure a different password storage mechanism by setting the following Ansible variable:
security_password_encrypt_method: SHA512
Warning
SHA512 is the default on most modern Linux distributions and it meets the requirement of the STIG. Do not change the value unless a system has a specific need for a different password mechanism.
The role ensures that crypt_style
is set to sha512
in
/etc/libuser.conf
, which is the default for CentOS 7 and Red Hat Enterprise
Linux 7.
Ubuntu, openSUSE and SUSE Linux Enterprise 12 do not use libuser
, so this change
is not applicable.
Deployers can opt out of this change by setting the following Ansible variable:
security_libuser_crypt_style_sha512: no
Although the STIG requires that all passwords have a minimum lifetime set, this can cause issue in some production environments. Therefore, deployers must opt in for this change.
Set the following Ansible variable to an integer (in days) to enable this setting:
security_password_min_lifetime_days: 1
The STIG requires the minimum lifetime for password to be one day.
Setting a minimum password lifetime on interactive user accounts provides security benefits by limiting the frequency of password changes. However, this can cause login problems for users without proper communication and coordination.
Deployers can opt-in for this change by setting the following Ansible variable:
security_set_minimum_password_lifetime: yes
The tasks will examine each interactive user account and set the minimum password age if the existing setting is not equal to one day.
Although the STIG requires that all passwords have a maximum lifetime set, this can cause authentication disruptions in production environments if users are not aware that their password will expire. Therefore, this change is not applied by default.
Deployers can opt in for this change and provide a maximum lifetime for user passwords (in days) by setting the following Ansible variable:
security_password_max_lifetime_days: 60
The STIG requires that all passwords expire after 60 days.
Although the STIG requires that a maximum password lifetime is set for all interactive user accounts, the security benefits of this configuration are debatable. The draft of NIST Publication 800-63B argues that password rotation may reduce overall security in some situations.
Deployers can opt-in for this change by setting the following Ansible variable:
security_set_maximum_password_lifetime: yes
The tasks will examine each interactive user account and set the maximum password age if the existing setting is not equal to 60 days.
Although the STIG requires that five passwords are remembered to prevent re- use, this can cause issues in production environment if the change is not communicated well to users. Therefore, the tasks in the security role do not apply this change by default.
Deployers can opt in for the change and specify a number of passwords to remember by setting the following Ansible variable:
security_password_remember_password: 5
Although the STIG requires that passwords have a minimum length of 15 characters, this change might be disruptive to users on a production system without communicating the change first. Therefore, this change is not applied by default.
Deployers can opt in for the change by setting the following Ansible variable:
security_pwquality_require_minimum_password_length: yes
The STIG requires that user accounts are disabled when their password expires. This might be disruptive for some users or for automated processes. Therefore, the tasks in the security role do not apply this change by default.
Deployers can opt in for this change by setting the following Ansible variable:
security_disable_account_if_password_expires: yes
The tasks in the Ansible role set a four second delay between failed login attempts. Deployers can configure a different delay (in seconds) by setting the following Ansible variable:
security_shadow_utils_fail_delay: 4
The STIG requires that the umask for all authenticated users is 077
. This
ensures that all new files and directories created by a user are accessible
only by that user.
Although this change has a significant security benefit, it can cause problems for users who are not expecting the change. The security role will not adjust the umask by default.
Deployers can opt-in for the change by setting the default umask with an Ansible variable:
security_shadow_utils_umask: 077
Note
Ubuntu, openSUSE Leap and SUSE Linux Enterpsise 12 use pam_umask
and it uses
the default umask provided by the UMASK
line in /etc/login.defs
.
The default setting on Ubuntu, openSUSE Leap and SUSE Linux Enterprise 12
systems is 022
. This allows the user’s group and other users on the
system to read and execute files, but they cannot write to them.
CentOS and Red Hat Enterprise Linux do not use pam_umask
and instead
set a default umask of 0002
for regular users and 0022
for root.
This gives the regular user’s group full access to newly created files, but
other users cannot write to those files.
The tasks for this STIG requirement are not currently applied to CentOS and Red Hat Enterprise Linux systems. See Launchpad Bug #1656003 for more details.
If any users are found with invalid GIDs, those users are printed in the
Ansible output. Deployers should review the list and ensure all users are
assigned to a valid group that is defined in /etc/group
.
If an account with UID 0 other than root
exists on the system, the playbook
will fail with an error message that includes the other accounts which have a
UID of 0.
Deployers are strongly urged to keep only one account with UID 0, root
, and
to use sudo
any situations where root access is required.
The usernames of all users without home directories assigned are provided in the Ansible console output. Deployers should use this list of usernames to audit each system to ensure every user has a valid home directory.
The CREATE_HOME
variable is set to yes
by the tasks in the security
role. This ensures that home directories are created each time a new user
account is created.
Deployers can opt out of this change by setting the following Ansible variable:
security_shadow_utils_create_home: no
Note
On CentOS 7, Red Hat Enterprise Linux 7 systems, openSUSE Leap and SUSE Linux Enterprise 12, home directories are always created with new users by default. Home directories are not created by default on Ubuntu systems.
Each interactive user on the system is checked to verify that their assigned home directory exists on the filesystem. If a home directory is missing, the name of the user and their assigned home directory is printed in the Ansible console output.
The security role can require new or changed passwords to follow the pwquality rules, but this change can be disruptive for users without proper communication. Deployers must opt in for this change by setting the following variable:
security_enable_pwquality_password_set: yes
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.