Verify Permissions on Backup passwd File
Ensures the backup file /etc/passwd- is not group/other-writable and carries no executable or special (setuid/setgid/sticky) bits, i.e. mode 0644 or stricter.
Checked against what is installed or registered, packages present/absent, account databases.
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
/etc/passwd- is the backup copy of /etc/passwd and lists every account, its UID/GID, home directory and login shell. If it is group/other-writable, an attacker could forge an account with UID 0 or change a shell in the backup; should /etc/passwd ever be restored from it, that change becomes live, a direct route to root. Mode 0644 or stricter, owned by root, keeps the backup tamper-resistant.
What Pavois checks
Pavois reads the live mode bits of /etc/passwd- via the InSpec file resource, the permissions the kernel enforces, not a packaging default. Backup files are easy to overlook and may be left writable by ad-hoc copies; inspecting the real inode catches that. The only_if guard skips the check when no backup exists yet.
only_if { file('/etc/passwd-').exist? }
describe file('/etc/passwd-') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endHow to verify it is applied
Run stat -c '%a %U %G %n' /etc/passwd-. Expected output is 644 root root /etc/passwd- (or stricter, e.g. 600).
Inspect & investigate
The backup is regenerated by account-management tools (useradd, usermod, vipw, passwd); their activity appears in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family). Track permission changes with an auditd watch and grep passwd- /var/log/audit/audit.log.
Remediation
No automated remediation is defined, so apply it manually: chown root:root /etc/passwd- && chmod u-x,g-wx,o-wx,a-s /etc/passwd- (a plain chmod 644 /etc/passwd- reaches the target mode).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0644 |
|---|---|
| path | /etc/passwd- |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: a writable passwd backup can be seeded with a UID-0 account that activates on restore. Precautions: tightening these permissions is safe, /etc/passwd- is read only by administrative tools running as root, and the world-readable default (0644) is acceptable since /etc/passwd itself is world-readable (it holds no password hashes). No service depends on a different mode, so there is no lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 7.1.2 | direct | per OS, see the benchmark table | high |
| NIST | AC-6 (1) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 2.2.6 | supporting | 4.0.1 | medium |
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.