Security
How CronCommander protects your infrastructure from RCE and privilege escalation.
Design Philosophy
CronCommander takes a defense-in-depth approach: we assume commands can be malicious and focus on limiting the blast radius rather than trying to detect dangerous commands.
; | && $() `
etc.)
because such filtering is easily bypassed and breaks legitimate automation. Instead, we enforce
strict
execution context controls.
Architecture: Dual-Mode Privilege
CronCommander 1.1+ supports two operation modes, allowing you to choose the right balance between convenience and security.
1. User Mode (Default & Recommended)
Principle: Least Privilege. The agent runs as a dedicated, unprivileged user
(cc-agent-user).
It cannot modify system files or access root resources. It manages jobs via its own user crontab.
- Daemon User:
cc-agent-user - Job User:
cc-agent-user(always) - Cron Mechanism: User crontab (
crontab -e) - Risk: Low. Compromise allows access only to agent resources.
2. System Mode (Opt-in)
Principle: Operator Control. The agent runs as root to maintain system-wide cron definitions. This is required if your jobs need to run as different users or require root privileges (e.g., system maintenance).
- Daemon User:
root - Job User:
root(by default) or explicitly specified users* - Cron Mechanism:
/etc/cron.d/croncommander - Risk: High. Compromise could yield root access. Use only in trusted environments.
* explicit user support coming in v1.2
Execution Context Hardening
1. Unprivileged User (`cc-agent-user`)
In User Mode, all jobs execute as the dedicated cc-agent-user system user, which has:
- No login shell (
/usr/sbin/nologin) - No password (account is locked)
- No sudo access
- Limited home directory (
/var/lib/croncommander)
2. Execution Mode Enforcement
The agent reports its execution mode during registration. The dashboard visualizes this:
- User badge: Running safely as unprivileged user.
- Root badge: Running with system privileges.
3. No New Privileges (Linux)
Regardless of mode, we set PR_SET_NO_NEW_PRIVS on Linux (kernel 3.5+) to prevent
privilege
escalation via setuid binaries during job execution.
4. Minimal Environment
Jobs execute with a restricted environment:
PATH=/usr/bin:/bin HOME=/var/lib/croncommander LANG=C.UTF-8
Auditability
Every job execution is logged with:
- Exact command (not redacted)
- Execution timestamp
- Executing UID and username
- Exit status
- stdout/stderr (up to 256KB)
- Security warnings (e.g., if job runs as unexpected user)
cc-agent-user to sudoers. This
would
defeat the security model.
What We Don't Do
CronCommander intentionally avoids:
- Command allowlists — too restrictive for real automation
- Regex-based "dangerous command" detection — easily bypassed
- Shell parsing or sanitization — complex and error-prone
- Metacharacter blocking — breaks legitimate use cases