Verify Group Who Owns /etc/crypttab File
Ensures the /etc/crypttab file is group-owned by root.
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
The /etc/crypttab file declares the system's encrypted block devices, the mapping names, backing devices, and key sources used to unlock them at boot. Group-owning this file by root keeps exclusive control of the encryption configuration: a non-root group owner could let an attacker read where keys live or tamper with the mappings, undermining full-disk encryption. Assigning the group to root ensures only highly-privileged accounts can influence how encrypted volumes are unlocked.
What Pavois checks
Pavois reads the effective group owner of /etc/crypttab on the live system via the InSpec file resource and asserts group == 'root'. It inspects the actual inode metadata as the kernel sees it, not a packaging default, so a file whose ownership drifted after install is caught.
only_if { file('/etc/crypttab').exist? }
describe file('/etc/crypttab') do
its('group') { should eq 'root' }
endHow to verify it is applied
Run stat -c '%G' /etc/crypttab. Expected output: root. Any other group name means the rule is not applied.
Inspect & investigate
Ownership changes are not logged by default. Watch the file with auditd: auditctl -w /etc/crypttab -p wa -k crypttab-perms, then inspect grep 'key="crypttab-perms"' /var/log/audit/audit.log. Encrypted-volume unlock activity at boot is visible via systemctl status 'systemd-cryptsetup@*' and journalctl -b -u 'systemd-cryptsetup@*'.
Remediation
Pavois's harden plan uses the file resource to set the group of /etc/crypttab to root, leaving content and permissions untouched. Apply it with pavois harden apply; Pavois re-reads the effective ownership afterward to confirm the rule passes.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | 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 group owner on /etc/crypttab weakens the trust boundary around disk encryption; restoring root ownership has no functional impact on booting or mounting. The fix only changes group ownership, not content or device mappings, so encrypted volumes still unlock normally. Precaution: do not edit the mapping lines or key-file paths while applying ownership, an incorrect crypttab entry can leave an encrypted volume unmountable at boot and hang or drop the system to an emergency shell.
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.