accounts - User account security controls

updated: 2019-10-14 18:16

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
updated: 2019-10-14 18:16
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug questions?