accounts - User account security controls¶
Security controls for user accounts on Linux systems are a crucial barrier to prevent unauthorized access.
Overview¶
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.
STIG requirements¶
All of the tasks for these STIG requirements are included in
tasks/rhel7stig/accounts.yml.
V-71903¶
Summary: When passwords are changed or new passwords are established, the new password must contain at least one upper-case character.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71905¶
Summary: When passwords are changed or new passwords are established, the new password must contain at least one lower-case character.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71907¶
Summary: When passwords are changed or new passwords are assigned, the new password must contain at least one numeric character.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71909¶
Summary: When passwords are changed or new passwords are assigned, the new password must contain at least one special character.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71911¶
Summary: When passwords are changed a minimum of eight of the total number of characters must be changed.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71913¶
Summary: When passwords are changed a minimum of four character classes must be changed.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71915¶
Summary: When passwords are changed the number of repeating consecutive characters must not be more than three characters.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71917¶
Summary: When passwords are changed the number of repeating characters of the same character class must not be more than four characters.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71919¶
Summary: The PAM system service must be configured to store only encrypted representations of passwords.
Severity: Medium
Implementation Status: Implemented
Deployer/Auditor notes¶
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.
V-71921¶
Summary: The shadow file must be configured to store only encrypted representations of passwords.
Severity: Medium
Implementation Status: Implemented
Deployer/Auditor notes¶
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.
V-71923¶
Summary: User and group account administration utilities must be configured to store only encrypted representations of passwords.
Severity: Medium
Implementation Status: Implemented - Red Hat Only
Deployer/Auditor notes¶
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
V-71925¶
Summary: Passwords for new users must be restricted to a 24 hours/1 day minimum lifetime.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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.
V-71927¶
Summary: Passwords must be restricted to a 24 hours/1 day minimum lifetime.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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.
V-71929¶
Summary: Passwords for new users must be restricted to a 60-day maximum lifetime.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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.
V-71931¶
Summary: Existing passwords must be restricted to a 60-day maximum lifetime.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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.
V-71933¶
Summary: Passwords must be prohibited from reuse for a minimum of five generations.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71935¶
Summary: Passwords must be a minimum of 15 characters in length.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71941¶
Summary: The operating system must disable account identifiers (individuals, groups, roles, and devices) if the password expires.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
V-71951¶
Summary: The delay between logon prompts following a failed console logon attempt must be at least four seconds.
Severity: Medium
Implementation Status: Implemented
Deployer/Auditor notes¶
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
V-71995¶
Summary: The operating system must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.
Severity: Medium
Implementation Status: Opt-In - Ubuntu And Suse Only
Deployer/Auditor notes¶
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.
V-72003¶
Summary: All Group Identifiers (GIDs) referenced in the /etc/passwd file must be defined in the /etc/group file.
Severity: Low
Implementation Status: Implemented
Deployer/Auditor notes¶
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.
V-72005¶
Summary: The root account must be the only account having unrestricted access to the system.
Severity: High
Implementation Status: Implemented
Deployer/Auditor notes¶
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.
V-72011¶
Summary: All local interactive users must have a home directory assigned in the /etc/passwd file.
Severity: Medium
Implementation Status: Implemented
Deployer/Auditor notes¶
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.
V-72013¶
Summary: All local interactive user accounts, upon creation, must be assigned a home directory.
Severity: Medium
Implementation Status: Implemented
Deployer/Auditor notes¶
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.
V-72015¶
Summary: All local interactive user home directories defined in the /etc/passwd file must exist.
Severity: Medium
Implementation Status: Implemented
Deployer/Auditor notes¶
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.
V-73159¶
Summary: When passwords are changed or new passwords are established, pwquality must be used.
Severity: Medium
Implementation Status: Opt-In
Deployer/Auditor notes¶
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
