Verify Permissions On /etc/sysctl.d Directory
Ensures the /etc/sysctl.d drop-in directory is writable only by root, so kernel-hardening parameters cannot be silently overridden at boot.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
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
The /etc/sysctl.d directory hosts kernel tuning drop-ins that are applied at boot (and by sysctl --system). These settings govern security-sensitive behaviour such as IP forwarding, ASLR, kptr_restrict and network hardening. If the directory is writable by group or other, a non-privileged user could drop in a file that disables a kernel protection on the next boot. Restricting write access to root only (no group/other write, no setuid/setgid/sticky) ensures exclusive control over the kernel configuration.
What Pavois checks
Pavois reads the effective directory mode of /etc/sysctl.d and asserts no write bit for group or other and no setuid/setgid/sticky bits. Guarded by only_if { file('/etc/sysctl.d').exist? }. Because sysctl is a drop-in mechanism, the security of the directory itself matters as much as individual files: a writable directory lets anyone add a new .conf that the kernel will honour, checking the live inode catches exactly that exposure.
only_if { file('/etc/sysctl.d').exist? }
describe file('/etc/sysctl.d') do
it { should_not be_setuid }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
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/sysctl.d. The expected output is 755 root root or stricter (e.g. 750): no write bit for group or other, and the directory owned by root. List the active values with sysctl --system to confirm only intended drop-ins are applied.
Inspect & investigate
stat /etc/sysctl.d shows the directory mode. To confirm the effective kernel state, query the live value, e.g. sysctl net.ipv4.ip_forward. Additions/changes under the directory appear in /var/log/audit/audit.log if an audit watch is configured.
Remediation
No automated harden plan is defined for this rule yet, so apply it manually: chown root:root /etc/sysctl.d then chmod 0755 /etc/sysctl.d (the directory must stay readable/traversable so sysctl --system can load the drop-ins).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0755 |
|---|---|
| path | /etc/sysctl.d |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A group- or world-writable /etc/sysctl.d lets an unprivileged user plant a drop-in that disables kernel protections (e.g. re-enabling ip_forward or weakening ASLR) on the next reboot, a stealthy persistence and privilege-weakening vector. Precautions: do not remove read/execute on the directory; the kernel and sysctl --system need to traverse it, so use 0755, not 0700, to avoid breaking boot-time application of your hardening parameters.
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.