Verify Group Who Owns cron.d
Ensures the /etc/cron.d directory is group-owned by root (gid 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
The /etc/cron.d directory holds drop-in crontab files that run as root on a fixed schedule. If the directory is group-owned by a non-privileged group, a member of that group could add, replace, or alter a cron job and obtain arbitrary command execution as root (privilege escalation). Restricting group ownership to root (gid 0) ensures only highly-privileged accounts can change what the system runs on a schedule.
What Pavois checks
Pavois reads the effective group owner of /etc/cron.d on the live system via the InSpec file resource and asserts gid == 0. It inspects the actual inode metadata as the kernel sees it (resolving symlinks and bind mounts), not a packaging manifest or a documented default, so a directory whose ownership was changed after install is caught.
only_if { file('/etc/cron.d').exist? }
describe file('/etc/cron.d') do
its('gid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%G %g' /etc/cron.d. Expected output: root 0. Any other group name or non-zero gid means the rule is not applied.
Inspect & investigate
Ownership changes are not logged by default. To observe a change, watch the file with auditd: auditctl -w /etc/cron.d -p wa -k cron-perms, then inspect events with grep 'key="cron-perms"' /var/log/audit/audit.log. Cron execution itself is visible in journalctl -u cron (Debian/Ubuntu) or journalctl -u crond (RHEL family).
Remediation
No automated remediation is defined for this rule, so it must be applied manually. Restore the correct group ownership with chgrp root /etc/cron.d (equivalently chown :root /etc/cron.d).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /etc/cron.d |
| 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/cron.d is a privilege-escalation path: group members can plant root-run jobs. Applying the fix is low-risk, chgrp root only changes group ownership, not permissions or content, and cron keeps working. Precaution: confirm no legitimate tooling depends on a custom group on this directory before changing it, and apply ownership before tightening any group-write permissions to avoid locking out an administrative workflow.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.7, 2.4.1.8 | direct | per OS, see the benchmark table | high |
| NIST | AC-6(1), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 2.2.6 | supporting | 4.0.1 | medium |
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.