Verify Permissions On /etc/crypttab File
Ensures /etc/crypttab is owned by root and not readable or writable by group/other, with no executable, setuid, setgid or sticky bits.
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/crypttab declares the encrypted block devices unlocked at boot, their mappings, options and, crucially, the path to key files. If it is readable by group or other, an attacker discovers the location of disk-encryption keys and the layout of protected volumes; if writable by non-root, they can redirect a mapping to a device they control or weaken cipher options. Restricting it to root keeps the encryption setup confidential and tamper-proof.
What Pavois checks
Pavois reads the real inode permissions of /etc/crypttab with the InSpec file resource (a stat), under only_if so hosts without disk encryption are skipped. It requires an effective mode no looser than 0600 root:root, no group/other read or write, no special bits. Inspecting the live permissions catches drift from a manual edit or a restore, which a packaged-default assumption would miss.
only_if { file('/etc/crypttab').exist? }
describe file('/etc/crypttab') 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 }
endHow to verify it is applied
Run stat -c '%a %U %G' /etc/crypttab. Expected output is mode 600 (or stricter) owned by root root, e.g. 600 root root. Any group/other read or write, or a special bit, fails the rule.
Inspect & investigate
Crypttab is consumed by systemd-cryptsetup at boot; check systemctl status 'systemd-cryptsetup@*' and journalctl -b -u 'systemd-cryptsetup@*' to confirm volumes unlock after any edit. There is no dedicated log for the permission itself, verify it with stat / getfacl /etc/crypttab.
Remediation
No automated remediation is defined, so apply it manually: chmod 0600 /etc/crypttab && chown root:root /etc/crypttab. No service reload is needed; the new permissions take effect immediately and are read at the next boot.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0600 |
|---|---|
| path | /etc/crypttab |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Tightening to 0600 root:root is safe, only the boot process (running as root) reads /etc/crypttab. There is no lockout risk from the permission change itself. Precaution: do not edit the file content while hardening; a malformed crypttab can prevent encrypted volumes from mounting at the next boot. Test on a non-critical reboot window if the host has root-on-LUKS. Leaving it world-readable exposes key-file paths to any local user.
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.