Verify User Who Owns /etc/crypttab File
Ensures the /etc/crypttab file is owned by the root user (UID 0).
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
/etc/crypttab describes the encrypted block devices unlocked at boot, including key file paths and cipher options. Ownership by root is critical: if a non-root user owns it, they could redirect a volume to an attacker-controlled key file, disable encryption options, or point a device at a malicious mapping, undermining the system's data-at-rest protection. Assigning ownership to root ensures exclusive control of the encrypted block devices configuration.
What Pavois checks
Pavois stats the live inode of /etc/crypttab and asserts its owner is UID 0. The check is skipped on systems without encrypted volumes (file absent). Reading the actual filesystem metadata reflects the effective ownership systemd-cryptsetup relies on at boot, not an assumed default.
only_if { file('/etc/crypttab').exist? }
describe file('/etc/crypttab') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u' /etc/crypttab. The expected output is root 0.
Inspect & investigate
Volume unlocking at boot is logged via journalctl -u systemd-cryptsetup@*. To detect tampering with the file, set an audit watch: auditctl -w /etc/crypttab -p wa -k crypttab, then review /var/log/audit/audit.log (grep for key="crypttab").
Remediation
No automated harden plan is defined for this rule yet, so it must be fixed manually: run chown root /etc/crypttab to restore root ownership.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| path | /etc/crypttab |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A non-root owner can tamper with the encrypted-device mapping and subvert disk encryption or cause boot failures. Fixing it is low-risk: chown root does not change the volume definitions, so unlocking continues to work. Verify nothing legitimately writes to /etc/crypttab as a non-root user before applying (rare); the change takes effect immediately, no reboot required.
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.