← All rules
SOCLE-CLD-FSP-145// File permissionsmediumpersistent config

Verify Permissions on /etc/security/opasswd.old File

Ensures the password-history backup /etc/security/opasswd.old is unreadable and unwritable by group and other (no setuid/setgid/sticky/exec), so only root can access the archived hashes.

Checked against the content of a persistent configuration file, the source of truth that survives reboots.

A pass proves? running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

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/security/opasswd.old is the backup of the PAM password-history file, automatically rotated when opasswd is updated. It contains the same old password hashes and is therefore just as sensitive as /etc/security/opasswd itself, a stale backup is just as crackable. If it is readable by group or other, those hashes leak; if writable, history integrity is lost. setuid/setgid/executable bits have no purpose. Only root must be able to read or write it.

What Pavois checks

Pavois reads the live mode bits of /etc/security/opasswd.old on the target, including the group/other read bit, because the backup carries the same crackable hashes as the live file. Permissions are inode metadata, so the audit reflects exactly what the kernel enforces. The only_if guard skips the control when no rotated backup exists.

only_if { file('/etc/security/opasswd.old').exist? }
describe file('/etc/security/opasswd.old') 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_readable.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_readable.by('other') }
  it { should_not be_sticky }
end

How to verify it is applied

Run stat -c '%A %U %G' /etc/security/opasswd.old. Expected: mode -rw------- (0600), or 0640 root:root at most, owned by root root, with no read/write bit for group or other. Quick check: find /etc/security/opasswd.old -perm /0177 must return nothing.

Inspect & investigate

Permission changes are not logged by default. Watch the backup with auditd alongside the live file: auditctl -w /etc/security/opasswd.old -p wa -k identity, then review with grep 'key="identity"' /var/log/audit/audit.log. PAM password-change activity appears in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL). Current mode and ownership: stat /etc/security/opasswd.old.

Remediation

No automated harden plan ships for this rule yet, so it must be applied manually: chown root:root /etc/security/opasswd.old && chmod 0600 /etc/security/opasswd.old. This removes all group/other access and any setuid/setgid/sticky bits from the password-history backup.

Pavois applies this with its own harden engine, the plan below, not a shell script:

mode0600
path/etc/security/opasswd.old
resourcefile
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Risk if left mis-set: a readable backup leaks old password hashes just like the live file, attackers often target .old/backup copies precisely because they are overlooked. Applying the fix is safe: 0600 root:root matches the live file's mode. Precaution: do not loosen to world-readable; this backup must mirror the strict permissions of /etc/security/opasswd.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS7.1.10directper OS, see the benchmark tablehigh

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.

Sources & references