CIS Ubuntu Linux 24.04 LTS Benchmark · Section 5

Ubuntu 24.04 Access Control: 9 Checks

Wartiva runs 9 checks for section 5, Access Control, of the CIS Ubuntu Linux 24.04 LTS Benchmark. Each one lists what it finds, why it matters, and how to fix it.

Wartiva evaluates these checks on its cloud mirror every time an endpoint changes, with zero endpoint load, and turns every failure into a finding with captured evidence. How Wartiva works →

All 9 checks on this page

5.2 Configure privilege escalation

Ensure sudo is installed

Medium severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.2

Finding: Sudo package is not installed.

Checks that one of the sudo or sudo-ldap packages is installed.

This rule fails when none of them is installed.

Rationale: sudo provides controlled, logged privilege escalation under the sudoers policy; without it there is no policy-mediated path to superuser access.

Impact: None; sudo is expected on managed systems.

Scope: Ubuntu 24.04 and later endpoints.

Remediation

From the command line:

apt install sudo
Framework mappings
  • CIS Controls v8: 5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts
  • NIST SP 800-53 Rev. 5: AC-2 Account Management; AC-6 Least Privilege
  • NIST SP 800-171 Rev. 2: 3.1.6 Use non-privileged accounts or roles when accessing nonsecurity functions; 3.1.7 Prevent non-privileged users from executing privileged functions and audit the execution of such functions
  • CMMC 2.0 Level 2: AC.L2-3.1.6 Use non-privileged accounts or roles when accessing nonsecurity functions; AC.L2-3.1.7 Prevent non-privileged users from executing privileged functions and audit the execution of such functions
Risk
External Attack Surface
MITRE ATT&CK tactic
Privilege Escalation (TA0004)

5.4 User Accounts and Environment

Ensure all users last password change date is in the past

Medium severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.4.1

Finding: User last password change date is in the future.

Checks that each local account's last-password-change date is at or before the current time.

This rule fails when a login account's lastPasswordChange date is in the future.

Rationale: A future-dated last-change timestamp lets an account indefinitely bypass password-expiration enforcement.

Impact: None; corrects an anomalous timestamp.

Remediation

From the command line:

chage -d "$(date +%Y-%m-%d)" <username>
Framework mappings
  • CIS Controls v8: 5.2 Use Unique Passwords
  • NIST SP 800-53 Rev. 5: IA-5 Authenticator Management
  • NIST SP 800-171 Rev. 2: 3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • CMMC 2.0 Level 2: IA.L2-3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • PCI DSS v4.0.1: 2.2.2 Reset passwords on, or disable, factory-supplied vendor accounts; 8.3.5 Use unique initial passwords and force change on first use; 8.3.6 Enforce 12-character minimum password length with letters and numbers; 8.6.3 Rotate and harden passwords for application and system-level accounts
Risk
Unprotected Principal
MITRE ATT&CK tactic
Credential Access (TA0006)

Ensure inactive password lock is configured

Medium severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.4.1

Finding: Inactive password lock exceeds 45 days.

Checks that each local account is disabled no more than 45 days after its password expires (and the value is not disabled/-1).

This rule fails when a login account's inactiveDaysAfterPasswordExpiry is negative or exceeds 45.

Rationale: Automatically disabling accounts after prolonged inactivity reduces the risk of unnoticed abuse of dormant credentials.

Impact: Accounts unused past the window after password expiry are locked and must be re-enabled by an administrator.

Remediation

From the command line:

chage --inactive 45 <username>
Framework mappings
  • CIS Controls v8: 5.2 Use Unique Passwords
  • NIST SP 800-53 Rev. 5: IA-5 Authenticator Management
  • NIST SP 800-171 Rev. 2: 3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • CMMC 2.0 Level 2: IA.L2-3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • PCI DSS v4.0.1: 2.2.2 Reset passwords on, or disable, factory-supplied vendor accounts; 8.3.5 Use unique initial passwords and force change on first use; 8.3.6 Enforce 12-character minimum password length with letters and numbers; 8.6.3 Rotate and harden passwords for application and system-level accounts
Risk
Unprotected Principal
MITRE ATT&CK tactic
Credential Access (TA0006)

Ensure minimum password days is configured

Medium severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.4.1

Finding: User minimum password age is not enforced.

Checks that each local account has a minimum password age of at least 1 day so passwords cannot be cycled repeatedly to defeat reuse controls.

This rule fails when a login account's passwordCanBeChangedAfter (min age, days) is less than 1.

Rationale: A non-zero minimum age prevents users from rapidly changing a password multiple times to bypass history/reuse restrictions.

Impact: A user cannot change their password again until the minimum interval elapses; may need a temporary reset to 0 for forced changes.

Remediation

From the command line:

chage --mindays 1 <username>
Framework mappings
  • CIS Controls v8: 5.2 Use Unique Passwords
  • NIST SP 800-53 Rev. 5: IA-5 Authenticator Management
  • NIST SP 800-171 Rev. 2: 3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • CMMC 2.0 Level 2: IA.L2-3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • PCI DSS v4.0.1: 2.2.2 Reset passwords on, or disable, factory-supplied vendor accounts; 8.3.5 Use unique initial passwords and force change on first use; 8.3.6 Enforce 12-character minimum password length with letters and numbers; 8.6.3 Rotate and harden passwords for application and system-level accounts
Risk
Unprotected Principal
MITRE ATT&CK tactic
Credential Access (TA0006)

Ensure password expiration is configured

High severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.4.1

Finding: User password expiration exceeds 365 days.

Checks that each local account's maximum password age is set to 365 days or fewer (and at least 1 day).

This rule fails when a login account's passwordValidFor (max age, days) is not between 1 and 365.

Rationale: Bounding password age limits the window in which a compromised credential remains usable.

Impact: Users must change their password at least yearly; the maximum age must exceed the minimum-days setting.

Remediation

From the command line:

chage --maxdays 365 <username>
Framework mappings
  • CIS Controls v8: 5.2 Use Unique Passwords
  • NIST SP 800-53 Rev. 5: IA-5 Authenticator Management
  • NIST SP 800-171 Rev. 2: 3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • CMMC 2.0 Level 2: IA.L2-3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • PCI DSS v4.0.1: 2.2.2 Reset passwords on, or disable, factory-supplied vendor accounts; 8.3.5 Use unique initial passwords and force change on first use; 8.3.6 Enforce 12-character minimum password length with letters and numbers; 8.6.3 Rotate and harden passwords for application and system-level accounts
Risk
Unprotected Principal
MITRE ATT&CK tactic
Credential Access (TA0006)

Ensure password expiration warning days is configured

Low severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.4.1

Finding: Password expiration warning is fewer than 7 days.

Checks that each local account is warned at least 7 days before its password expires.

This rule fails when a login account's warningDaysBeforePasswordExpires is less than 7.

Rationale: Advance warning gives users time to choose a strong replacement password rather than being forced to pick one hastily.

Impact: None material.

Remediation

From the command line:

chage --warndays 7 <username>
Framework mappings
  • CIS Controls v8: 5.2 Use Unique Passwords
  • NIST SP 800-53 Rev. 5: IA-5 Authenticator Management
  • NIST SP 800-171 Rev. 2: 3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • CMMC 2.0 Level 2: IA.L2-3.5.7 Enforce a minimum password complexity and change of characters when new passwords are created
  • PCI DSS v4.0.1: 2.2.2 Reset passwords on, or disable, factory-supplied vendor accounts; 8.3.5 Use unique initial passwords and force change on first use; 8.3.6 Enforce 12-character minimum password length with letters and numbers; 8.6.3 Rotate and harden passwords for application and system-level accounts
Risk
Unprotected Principal
MITRE ATT&CK tactic
Credential Access (TA0006)

Ensure system accounts do not have a valid login shell

High severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.4.2

Finding: System account has a valid login shell.

Checks that service/system accounts are assigned a non-login shell (nologin or false) so they cannot be used for interactive access.

This rule fails when a system account (uid < 1000, not root) has an interactive login shell.

Rationale: System accounts exist to run services, not for interactive login; a real shell on them expands the attack surface for lateral movement and persistence.

Impact: None for accounts that never log in interactively.

Remediation

From the command line:

usermod -s $(command -v nologin) <username>
Framework mappings
  • CIS Controls v8: 3.3 Configure Data Access Control Lists
  • NIST SP 800-53 Rev. 5: AC-3 Access Enforcement; AC-5 Separation of Duties; AC-6 Least Privilege; CA-3 Information Exchange; MP-2 Media Access
  • NIST SP 800-171 Rev. 2: 3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems); 3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute; 3.8.2 Limit access to CUI on system media to authorized users
  • CMMC 2.0 Level 1: AC.L1-b.1.i Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems); AC.L1-b.1.ii Limit information system access to the types of transactions and functions that authorized users are permitted to execute
  • CMMC 2.0 Level 2: AC.L2-3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems); AC.L2-3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute; MP.L2-3.8.2 Limit access to CUI on system media to authorized users
  • PCI DSS v4.0.1: 1.3.1 Limit inbound CDE traffic to what is necessary, denying the rest; 7.1 Governance processes for need-to-know access restriction are established
Risk
Unprotected Principal
MITRE ATT&CK tactic
Privilege Escalation (TA0004)

Ensure root is the only UID 0 account

High severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.4.2

Finding: An account other than root has UID 0.

Checks each account for UID 0, which grants full superuser privileges.

This rule fails for an account other than root with UID 0, and for root when another account shares its UID.

Rationale: Any UID 0 account has full superuser privileges; limiting UID 0 to root keeps a single, auditable superuser identity.

Impact: Reassigning UID of any additional UID-0 account may affect file ownership for that account.

Scope: Ubuntu 24.04 and later endpoints.

Remediation

For every account other than root that has UID 0, assign a new unique non-zero UID with usermod -u <newUID> <name>, or remove the account.

Framework mappings
  • CIS Controls v8: 3.3 Configure Data Access Control Lists
  • NIST SP 800-53 Rev. 5: AC-3 Access Enforcement; AC-5 Separation of Duties; AC-6 Least Privilege; CA-3 Information Exchange; MP-2 Media Access
  • NIST SP 800-171 Rev. 2: 3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems); 3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute; 3.8.2 Limit access to CUI on system media to authorized users
  • CMMC 2.0 Level 1: AC.L1-b.1.i Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems); AC.L1-b.1.ii Limit information system access to the types of transactions and functions that authorized users are permitted to execute
  • CMMC 2.0 Level 2: AC.L2-3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems); AC.L2-3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute; MP.L2-3.8.2 Limit access to CUI on system media to authorized users
  • PCI DSS v4.0.1: 1.3.1 Limit inbound CDE traffic to what is necessary, denying the rest; 7.1 Governance processes for need-to-know access restriction are established
Risk
Unprotected Principal
MITRE ATT&CK tactic
Privilege Escalation (TA0004)

Ensure root is the only GID 0 account

Medium severity · Wartiva check · CIS Ubuntu Linux 24.04 LTS Benchmark 5.4.2

Finding: An account other than root has GID 0.

Checks each account's primary group for GID 0, the root group.

This rule fails for an account other than root whose primary group is GID 0.

Rationale: Restricting primary GID 0 to root helps prevent root-owned files from becoming group-accessible to unintended accounts.

Impact: Changing an account's primary GID may affect ownership of files it creates.

Scope: Ubuntu 24.04 and later endpoints.

Remediation

Assign this account a primary group other than GID 0 with usermod -g <GID> <name>, or remove the account. Only root should have primary GID 0.

Framework mappings
  • CIS Controls v8: 3.3 Configure Data Access Control Lists
  • NIST SP 800-53 Rev. 5: AC-3 Access Enforcement; AC-5 Separation of Duties; AC-6 Least Privilege; CA-3 Information Exchange; MP-2 Media Access
  • NIST SP 800-171 Rev. 2: 3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems); 3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute; 3.8.2 Limit access to CUI on system media to authorized users
  • CMMC 2.0 Level 1: AC.L1-b.1.i Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems); AC.L1-b.1.ii Limit information system access to the types of transactions and functions that authorized users are permitted to execute
  • CMMC 2.0 Level 2: AC.L2-3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems); AC.L2-3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute; MP.L2-3.8.2 Limit access to CUI on system media to authorized users
  • PCI DSS v4.0.1: 1.3.1 Limit inbound CDE traffic to what is necessary, denying the rest; 7.1 Governance processes for need-to-know access restriction are established
Risk
Unprotected Principal
MITRE ATT&CK tactic
Privilege Escalation (TA0004)