Verify pam_unix module is activated
Confirms the core pam_unix.so module is present in the PAM stack so that local credential checks against /etc/shadow are actually performed.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
pam_unix.so is the module that actually checks credentials against the local password database (/etc/shadow). If it is missing from the PAM stack, the system may grant access without performing any local authentication, breaking the most basic security guarantee that access follows a successful identity check.
What Pavois checks
Pavois greps the effective PAM tree under /etc/pam.d/ for a non-commented pam_unix.so line. Scanning the resolved configuration, including files pulled in by @include/substack, proves the module is wired into the live authentication path, not just present in some unreferenced file a file-by-file check might wrongly trust.
describe command('grep -RqE \'^[^#]*\bpam_unix\\.so\b\' /etc/pam.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run:
grep -rE '^[^#]*\bpam_unix\.so\b' /etc/pam.d/
Expected: one or more active lines (in common-auth, common-password, system-auth…) reference pam_unix.so. No match means local PAM authentication is not configured.
Inspect & investigate
Login and authentication attempts handled by pam_unix are recorded in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/Fedora). Use journalctl -t sshd -t login -t sudo to follow successful and failed pam_unix decisions in real time.
Remediation
No automated harden plan ships for this rule, so it must be applied manually. On a normally installed system pam_unix.so is present by default; if it has been removed, restore it in the auth, account, password and session stacks via pam-auth-update (Debian/Ubuntu) or authselect select (RHEL/Fedora) rather than editing PAM files by hand.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | grep -rE 'pam_unix\.so' /etc/pam.d/ || echo 'pam_unix MISSING' # pam_unix is part of debian's default profiles; if missing, restore with: pam-auth-update |
|---|---|
| reason | PAM stack changes go through pam-auth-update, review the profile set |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A PAM stack missing pam_unix.so is severe, it can allow unauthenticated access or, conversely, lock everyone out depending on what replaced it. Precautions: keep a root shell open before touching PAM, make changes through pam-auth-update/authselect (which validate the stack), and confirm you can still log in from a separate session before closing your current one.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.3.2.1, 5.3.2.5 | direct | per OS, see the benchmark table | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.