Verify No netrc Files Exist
Ensures no .netrc file exists under /root or /home, eliminating plaintext stored remote credentials.
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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
A ~/.netrc file stores credentials (login and plaintext password) for remote FTP/HTTP servers so tools like ftp, curl and git can authenticate non-interactively. Because the passwords are unencrypted, anyone who reads the file, through a permissions slip, a backup, or compromise of the account, instantly harvests reusable credentials for other systems. Hardened hosts should carry no .netrc files; use a credential helper or a secrets store instead.
What Pavois checks
Pavois runs a live find over /root and /home (single filesystem via -xdev) for any file named .netrc. Enumerating files actually present on disk catches credential files in every home, including newly created or non-standard accounts, instead of relying on a fixed user list.
describe command('find /root /home -xdev -name .netrc 2>/dev/null') do
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Search for any netrc file:
find /root /home -xdev -name .netrc 2>/dev/null, expected output is empty (no path printed).
Inspect & investigate
.netrc usage is not itself logged, so detection is filesystem-based and best paired with file-integrity monitoring:
find /root /home -xdev -name .netrc -printf '%p %u %m\n', lists each file with owner and mode for review.- If auditd is configured, a watch on home directories (
/var/log/audit/audit.log) records creation of new dotfiles.
Remediation
No automated harden plan is defined for this rule yet, so it must be applied manually: review each file found (find /root /home -xdev -name .netrc), rotate any credential it exposes because it must be considered compromised, then delete the file with rm <path>. Replace the workflow with a credential helper or a secrets manager.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | find /home /root -maxdepth 2 -name .netrc 2>/dev/null # rm -f <path> per file (or chmod 600) after review |
|---|---|
| reason | a .netrc holds credentials, review each before deleting |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: plaintext credentials for remote services sit on disk, ready to be harvested and reused for lateral movement.
Precautions before applying: automated jobs (backups, CI runners, FTP scripts) may depend on a .netrc. Identify those consumers and migrate them to a secrets store or a per-call credential helper before deleting, or the job will fail. Treat any password found as already exposed and rotate it regardless.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 7.2.10, 7.2.9 | direct | per OS, see the benchmark table | high |
| NIST | CM-6(a), IA-5(1)(c), IA-5(7), IA-5(h) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | 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.