Learning Cron Job - Crontab Security: Allow/Deny

#Introduction

In episode 12 we made job failures visible. Now we handle the dark side: crontab is an execution path. Anyone who can write a crontab as a given user can run commands as that user — and if that user is root, they control the entire server.

Cron security isn't about disabling features; it's about controlling who can schedule what, and limiting the privileges jobs hold. This episode covers the two main access control files and the principle of least privilege.

#Access Control: cron.allow and cron.deny

#The Two Files That Decide Permissions

Cronie checks two files when a user calls crontab:

/etc/cron.allow — the list of users allowed to create a crontab.
/etc/cron.deny — the list of users denied from creating a crontab.

The priority rules:

If /etc/cron.allow exists, only listed users may use cron — everyone else is denied.
If /etc/cron.allow doesn't exist, all users may — except those listed in /etc/cron.deny.
If neither exists, on many distros only root may (depending on configuration).

Lihat file kontrol cron

cat /etc/cron.allow 2>/dev/null
cat /etc/cron.deny 2>/dev/null

#The Default Deny Strategy

For servers with many accounts, the safest strategy: default deny — allow only the users who genuinely need it:

/etc/cron.allow

root
deploy
backup

With this file present, other users (e.g. an account created for a web app) cannot create a crontab — even with shell access. This closes one common privilege escalation path: a restricted user finding a way to periodically run commands as another user.

Warning

Root is always allowed to use cron, whatever cron.deny contains — this behavior is built-in and intentional. That means securing cron can never replace securing the root account itself. cron.allow protects against other users, not against a compromised root.

#Managing the Permission Files

Tambahkan user ke cron.allow

echo deploy >> /etc/cron.allow
sudo visudo -f /etc/cron.allow  # atau edit manual sebagai root

Always keep these files' permissions tight:

Perkuat permission file izin

sudo chmod 600 /etc/cron.allow
sudo chown root:root /etc/cron.allow

#Privilege: Don't Run Jobs as Root Without Need

#The Principle of Least Privilege

The same principle applies to cron as to any other system: give the least privilege possible. Running every job as root means a single bug in a backup script could wipe the entire system — because that script runs with full power.

The rule is simple:

A job that only needs to read/write certain directories → run it as a dedicated user.
A job that needs a database → run it as a user with restricted database access.
Root only for things that genuinely need root.

#Create Dedicated Task Users

The recommended pattern: one dedicated user per heavy task:

Buat user khusus backup

sudo useradd --system --shell /usr/sbin/nologin --create-home backup

Then manage its crontab as root:

Edit crontab user backup

sudo crontab -u backup -e

Separate file access with permissions:

Beri akses terbatas ke direktori data

sudo chown -R backup:backup /backup
sudo chmod -R 700 /backup

Tip

Use the nologin shell for dedicated task users. These users must not log in — they only serve as an identity to run jobs. A user's crontab still works even with a nologin shell, because cron executes commands directly, not through login.

#Security Control Summary

Step	Tool	Effect
Limit who can create crontabs	`/etc/cron.allow`	Default deny for non-root
Reduce job privileges	Dedicated user	A bug doesn't become root
Lock permission files	`chmod 600`	Prevent tampering
Review schedules	Periodic `crontab -l`	Find suspicious jobs

#Closing

Key takeaways:

/etc/cron.allow = whitelist of users allowed to use cron.
/etc/cron.deny = blacklist; only applies if allow doesn't exist.
Use default deny on servers with many accounts.
Don't run jobs as root without a genuine need.
Create dedicated task users with a nologin shell and restricted file access.

In episode 14 we'll cover safe scripting and secrets — how to avoid hardcoded passwords in crontab, use env files with 600 permissions or Vault, and script discipline with set -euo pipefail, absolute paths, and input validation!