Verify Permissions On /etc/ipsec.d Directory
Ensures the /etc/ipsec.d directory is not readable, writable or executable by group/other and carries no setuid, setgid or sticky bit (expected mode 0700 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.d/ holds the IPsec secrets material: certificates, private keys, CRLs and per-connection configuration drop-ins for Libreswan/strongSwan. If the directory is readable by group or other, an attacker can list and copy private keys, breaking the confidentiality of every tunnel; if writable, they can plant a rogue key or config. Restricting it to root (mode 0700) keeps the VPN's cryptographic material private and tamper-proof.
What Pavois checks
Pavois reads the real inode permissions of the /etc/ipsec.d directory with the InSpec file resource (a stat), under only_if. For a directory, the group/other read bit allows listing and execute allows traversal, so both are forbidden along with write and any setuid/setgid/sticky bit, effectively 0700 root:root. Inspecting the live directory mode catches drift from a manual change or a restore that a packaged-default assumption would miss.
only_if { file('/etc/ipsec.d').exist? }
describe file('/etc/ipsec.d') do
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 }
endHow to verify it is applied
Run stat -c '%a %U %G' /etc/ipsec.d. Expected output is mode 700 owned by root root, i.e. 700 root root. Any group/other read, write or execute bit, or a special bit, fails the rule.
Inspect & investigate
The IPsec daemon loads keys and certs from this directory; check journalctl -u ipsec / journalctl -u strongswan and ipsec status to confirm tunnels still negotiate after a permission change. Use ls -ld /etc/ipsec.d / stat /etc/ipsec.d to verify the mode.
Remediation
No automated remediation is defined, so apply it manually: chmod 0700 /etc/ipsec.d && chown root:root /etc/ipsec.d. Consider tightening the key files inside (chmod 0600 /etc/ipsec.d/private/*) as well, then ipsec reload.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0700 |
|---|---|
| path | /etc/ipsec.d |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Setting 0700 root:root on the directory is safe, the IPsec daemon runs as root and retains full access. There is no lockout risk. Precaution: if a non-root monitoring or backup user previously read this directory, it will lose access; that is intended for secret material, but adjust your tooling to run privileged instead. Verify tunnels with ipsec status afterwards. Leaving the directory world-readable exposes private VPN keys.
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.