Ensure permissions on /etc/crontab are configured is a CIS Linux benchmark check that fails when the system crontab is not owned by root:root or is accessible to group or other users. Fix it with chown root:root /etc/crontab and chmod og-rwx /etc/crontab (mode 0600), repeat for the cron.hourly, cron.daily, cron.weekly, cron.monthly and cron.d directories (0700), then rescan.

What the scanner is actually detecting

This finding comes from Tenable’s CIS Linux audit files, which Nessus runs as a credentialed Unix compliance check. It is a configuration check, not a vulnerability plugin, so there is no CVE and nothing to patch. The item number changes with the benchmark release. You will see it as 5.1.2 Ensure permissions on /etc/crontab are configured in older audits such as CIS Ubuntu 16.04 LTS Server v2.0.0 and CIS Amazon Linux 2 v2.0.0, as 4.1.2 in releases such as CIS Ubuntu 20.04 LTS v2.0.1, and as 2.4.1.2 in current audits such as CIS Rocky Linux 9 v2.0.0 and CIS Debian Linux 11 v2.0.0. Tenable files it under Access Control and Media Protection.

The check expects /etc/crontab to be owned by user root and group root, with no permissions at all for group and other. The same benchmarks carry one sibling item per cron directory, for example 2.4.1.3 for /etc/cron.hourly through 2.4.1.7 for /etc/cron.d in the Rocky Linux 9 audit, each with the same owner and mode rule. A host that fails one of them usually fails all six, so fix them together. Newer releases (for example CIS Rocky Linux 10 v1.0.0) reword the titles as Ensure access to /etc/cron.hourly is configured, but the remediation is unchanged. Current benchmarks scope these items to systems where cron is installed.

Real-world risk

On most hosts this item fails simply because the distribution ships /etc/crontab as world-readable (commonly 0644) and the cron directories as 0755. That exposes what root runs and when, not the ability to change it. The CIS rationale is that read access gives an unprivileged user insight into system jobs, which can point to a weaker link: a script that root runs from cron but that sits in a writable location, or a job command line that contains a password or token.

The serious case is write access. If a non-root user or group can write to /etc/crontab, to a cron directory, or to a file inside one, that user can schedule commands as root. The cron daemon itself refuses some of this: the Debian cron manual states that /etc/crontab and files in /etc/cron.d must be owned by root and must not be group- or other-writable, and cronie has a similar rule. That protection does not cover scripts dropped into cron.daily and its siblings, which run-parts executes. Treat this finding as low-severity hardening unless your confirmation step turns up write access, in which case it is urgent.

How to confirm it on the host

Print owner, group and octal mode for the file and the directories:

stat -c '%a %U:%G %n' /etc/crontab /etc/cron.hourly /etc/cron.daily 
  /etc/cron.weekly /etc/cron.monthly /etc/cron.d

A failing host typically shows 644 root:root /etc/crontab and 755 root:root for the directories. Then look for the dangerous case, anything under these paths that is group- or other-writable or not owned by root:

sudo find /etc/crontab /etc/cron.hourly /etc/cron.daily /etc/cron.weekly 
  /etc/cron.monthly /etc/cron.d ( -perm /022 -o ! -user root ) -ls

Any output here deserves investigation before you simply fix modes, because it may indicate an existing compromise or a package that installed files with the wrong owner. Finally, a trailing + in ls -ld /etc/crontab /etc/cron.* means a POSIX ACL is set; list it with getfacl.

How to fix it

The commands are the same on RHEL and its rebuilds, Amazon Linux, SUSE, Debian and Ubuntu. First save the current state so you can restore it exactly:

sudo getfacl -p /etc/crontab /etc/cron.hourly /etc/cron.daily /etc/cron.weekly 
  /etc/cron.monthly /etc/cron.d | sudo tee /root/cron-perms-backup.acl > /dev/null

Option 1: the benchmark commands

sudo chown root:root /etc/crontab
sudo chmod og-rwx /etc/crontab

for d in /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /etc/cron.d; do
  [ -d "$d" ] && sudo chown root:root "$d" && sudo chmod og-rwx "$d"
done

Starting from the usual defaults, this yields 0600 for the file and 0700 for the directories. The symbolic form only removes group and other bits, so it never strips the owner’s execute bit on a directory. If /etc/cron.yearly exists on your distribution, treat it the same way. If the confirmation step found an ACL, remove it with sudo setfacl -b on the affected path.

Option 2: explicit modes in configuration management

Enforcing the state from Ansible (or your equivalent tool) keeps it from drifting after package updates or manual changes:

- name: Restrict /etc/crontab
  ansible.builtin.file:
    path: /etc/crontab
    state: file
    owner: root
    group: root
    mode: "0600"

- name: Restrict cron directories
  ansible.builtin.file:
    path: "{{ item }}"
    state: directory
    owner: root
    group: root
    mode: "0700"
  loop:
    - /etc/cron.hourly
    - /etc/cron.daily
    - /etc/cron.weekly
    - /etc/cron.monthly
    - /etc/cron.d

Do not run a recursive numeric chmod -R 600 on these directories. Scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly are run by run-parts and must stay executable, and the directories need the owner execute bit to be searched. No restart is needed: the cron daemon runs as root, still reads everything, and the cronie manual states that there is no need to restart cron after crontabs are modified.

How to verify the fix and rescan

stat -c '%a %U:%G %n' /etc/crontab /etc/cron.hourly /etc/cron.daily 
  /etc/cron.weekly /etc/cron.monthly /etc/cron.d
sudo -u nobody cat /etc/crontab
sudo -u nobody ls /etc/cron.d

Expect 600 root:root for the file, 700 root:root for each directory, and Permission denied for both commands run as nobody. After the next scheduled run, confirm jobs still execute by checking the cron log (journalctl -u crond on RHEL-family systems, journalctl -u cron on Debian and Ubuntu). Then rerun the same compliance scan, with the same audit file and credentials, against the host.

What can break and how to roll back

Unprivileged readers. Monitoring agents, inventory scripts or backup checks that run as a non-root user and parse /etc/crontab or list /etc/cron.d will now get permission errors. Run them as root or through a narrowly scoped sudo rule.
Scheduled jobs are not affected. Cron reads these paths as root, and jobs in /etc/cron.d that specify another user still run as that user.
Integrity tools will notice. rpm -Va reports a mode difference (the M flag) for package-owned paths you changed. Document it as an intentional deviation so it is not chased as tampering.
Drift. A package upgrade or a manual edit can bring back the old modes. On Debian and Ubuntu, dpkg-statoverride can pin an owner and mode for a path across package installs; otherwise rely on configuration management and periodic rescans.

To roll back to exactly the saved state:

sudo setfacl --restore=/root/cron-perms-backup.acl

Or return to the common defaults by hand with sudo chmod 0644 /etc/crontab and sudo chmod 0755 on each directory.

Common false positive reasons

Stale results. The report predates the change, or the rescan used a different audit file, benchmark version or credentials.
Several items, one fix. Each directory is a separate item with its own title. Fixing /etc/crontab alone leaves the cron.d and periodic directory findings open; they are real, not duplicates.
Cron is not in use. Current benchmarks apply these items only if cron is installed. If a host was hardened by removing cron but files remain, check the owner with rpm -qf /etc/crontab or dpkg -S /etc/crontab and confirm which profile the scan applied.
Wrong benchmark profile. An audit for a different distribution or release can report paths or numbering that do not match the host.

A mode that reverted after a patch cycle is not a false positive. It is drift, and the fix is to enforce the mode rather than to accept the finding.

FAQ

Will cron jobs stop running after chmod og-rwx /etc/crontab?

No. The cron daemon runs as root and still has full access to the file and the directories. Only non-root users lose the ability to read them.

Why 0600 when my distribution ships 0644?

Distribution defaults favor convenience. The CIS benchmarks treat the list of root-run jobs as sensitive, so they require that only the owner, root, can access it.

Do I need to restart cron?

No. Changing owner and mode does not change the job definitions, and both the cronie and Debian cron manuals state that cron does not need a restart when crontabs are modified.

We only use systemd timers. Should we remove cron instead?

Some benchmark releases say so directly: if another method such as systemd timers is used, cron should be removed and the alternative secured according to local site policy, and the CIS Amazon Linux 2 v2.0.0 audit lists yum remove cronie as an alternative fix. Check /etc/crontab, /etc/cron.d and the periodic directories for live jobs before removing anything.

Tracking this finding across many hosts

This is the kind of configuration finding that appears on every Linux host in a compliance scan and then quietly drifts back. The same class of weak scheduler permissions exists on Windows too, covered in our guide to auditing weak permissions on scheduled tasks and autoruns. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results arrive as an uploaded .nessus export) and merges duplicates reported by the same scanner. Its AI can draft host-specific remediation scripts that run only after human approval, deployed by SITEY agents on Linux endpoints, and SITEY re-tests afterward to verify closure.

Discovery and visibility

Scanning and collection

The AI layer

Action and closure

Team and governance

Reporting

Ensure Permissions on /etc/crontab Are Configured: How to Fix the CIS Finding