Linux cron安全管理需闭环控制“谁在跑、跑什么、在哪跑、如何审计”：严格限制用户范围、禁用高危指令、统一管控系统级任务路径权限、启用执行日志与变更审计。
Linux 定时任务（cron）是系统自动化运维的核心机制，但若配置不当或权限失控，极易成为安全风险入口——比如提权执行、敏感信息泄露、被恶意篡改植入后门等。安全管理的关键不在禁用 cron，而在于“谁在跑、跑什么、在哪跑、如何审计”四个维度的闭环控制。
严格限制可编辑定时任务的用户范围
cron 的全局控制依赖于 /etc/cron.allow 和 /etc/cron.deny 文件。默认多数发行版仅检查 cron.deny（空文件表示所有用户可用），这存在明显隐患。
- 生产环境应显式创建 /etc/cron.allow，仅写入必需用户（如 root、backup、monitor），并确保该文件权限为 600
- 删除或清空 /etc/cron.deny，避免与 allow 文件逻辑冲突
- 普通用户如需定时任务，应通过运维流程申请，并由管理员统一在 /etc/cron.d/ 下以独立文件方式部署，而非开放 crontab -e 权限
禁止在用户 crontab 中使用高危指令
用户级 crontab（crontab -e）缺乏上下文隔离，易被滥用。需通过策略和检查双管齐下：
- 禁止直接调用 bash -c、sh -c、eval 或拼接变量的命令（如 "$CMD"），防止命令注入
- 脚本路径必须使用绝对路径，且目标文件属主为 root 或任务专属用户，权限不高于 750（目录）或 640（脚本）
- 定期用以下命令扫描风险项：
grep -r "bash -c\|sh -c\|eval\|\$\(" /var/spool/cron/ /etc/cron.d/ 2>/dev/null
统一管控系统级定时任务路径与权限
系统级任务分布在多个位置，需统一治理：
- /etc/crontab：仅保留基础系统任务（如 logrotate），注释说明每行用途，禁止添加业务逻辑
- /etc/cron.d/：每个文件对应一个服务或模块，命名清晰（如 app-monitor），文件权限设为 644，属主 root:root
- /etc/cron.hourly /daily /weekly /monthly：只允许放入已签名、经审核的 shell 脚本；禁止软链接指向用户家目录或临时路径
- 所有上述路径下的文件，禁止包含 PATH= 覆盖或 SHELL= 指定非标准解释器
启用执行日志与变更审计
默认 cron 日志粒度粗、易被绕过。必须增强可观测性：
- 在 /etc/rsyslog.conf 或 /etc/rsyslog.d/50-cron.conf 中启用 cron 日志：
cron.* /var/log/cron.log，并重启 rsyslog - 对所有定时任务脚本启用执行记录，在脚本开头加入：
echo "$(date): START $0 $*" >> /var/log/cron-exec.log - 用 auditd 监控关键路径变更：
auditctl -w /etc/cron* -p wa -k cron_conf，并定期用 ausearch -k cron_conf 审查 - 将 /var/spool/cron/ 和 /etc/cron.d/ 加入文件完整性监控（如 aide 或 tripwire）
