Ensure only authorized system accounts can obtain access
authorized-service-accounts · RHEL ≥ 8, UBUNTU ≥ 22 · 1 impl
Description
System accounts (UID below 1000) exist to run services, not to log in. Any system account holding a real login shell can obtain access to the host, so it must be one the site authorized. The authorized set is a statement about what this system runs, so it cannot be derived from the host: an operator declares it in the authorized_service_accounts variable, as account names, numeric UIDs, or a mix. Until it is declared the check reports that it cannot assess the host and names what to set.
Rationale
A service identity with a login shell is an account, whatever it was created for. It is also the quietest way onto a machine: nobody audits the shell field of an account named after a daemon, and package installs add system accounts without anyone deciding they should. Listing every system account would be no use, because a base install carries two dozen and a list nobody maintains stops being true within a year. Listing only the ones that can actually obtain access is short enough to stay accurate, and it is the set the control is about.
Check → Remediate
- observed_command:
- awk -F: '$3 < 1000 && $7 !~ /(nologin|false|sync|shutdown|halt)$/ {print $1":"$3}' /etc/passwd
- authorized:
- {{ authorized_service_accounts }}
- alias_separator:
- :
- note:
- For each account reported as not authorized, decide which side is wrong. If it does not need to log in, give it a non-login shell (usermod -s /sbin/nologin <name>), which is the fix in almost every case. If it genuinely needs one, add it to authorized_service_accounts so the declared set matches what this system runs. Kensa does not change the shell automatically: an account that legitimately runs a login shell is rare but real, and taking it away can stop the service the host exists for.
Framework references
NIST 800-53
NIST 800-171
CMMC Level 2