Verify Permissions On /etc/ipsec.secrets File
Ensures /etc/ipsec.secrets is not writable or executable by group/other and free of setuid, setgid or sticky bits (target mode 0600 root:root).
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
/etc/ipsec.secrets stores the IPsec authentication secrets, pre-shared keys (PSKs) and references to private keys used to authenticate VPN peers. Anyone who can read it can impersonate a tunnel endpoint or decrypt captured traffic; anyone who can write it can substitute their own secret. It must be restricted to root (ideally 0600) to keep VPN credentials confidential and authentic.
What Pavois checks
Pavois reads the real inode permissions of /etc/ipsec.secrets with the InSpec file resource (a stat), under only_if. It forbids group/other write and execute and any setuid/setgid/sticky bit. Because this file contains secrets, the recommended target is 0600 root:root (the check enforces at least no group/other write/execute; pair it with manual chmod 0600 to also remove read). Reading the live mode catches drift a packaged-default check would miss.
only_if { file('/etc/ipsec.secrets').exist? }
describe file('/etc/ipsec.secrets') 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' /etc/ipsec.secrets. Expected output is mode 600 owned by root root, i.e. 600 root root. Any group/other read, write or execute, or a special bit, indicates a problem.
Inspect & investigate
Secret loading and authentication results are logged by the daemon: journalctl -u ipsec / journalctl -u strongswan; ipsec status confirms tunnels authenticate. After editing secrets, run ipsec secrets (Libreswan) to reload them and check no auth errors appear.
Remediation
No automated remediation is defined, so apply it manually: chmod 0600 /etc/ipsec.secrets && chown root:root /etc/ipsec.secrets, then reload secrets with ipsec secrets (or ipsec reload).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0644 |
|---|---|
| path | /etc/ipsec.secrets |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Setting 0600 root:root is safe, the IPsec daemon reads secrets as root. The permission change cannot drop a tunnel by itself. Precaution: do not alter the secret values while hardening; an invalid PSK or key reference will cause authentication failures and tunnels will fail to come up on the next reload. Verify with ipsec status afterwards. Leaving the file readable lets a local user steal PSKs and impersonate a peer.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | 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.