T06 · System Persistence
- Location
scripts/setup.sh:150- Finding
Default Installation of a Persistent Nightly Cron Job
- Content
View full analysis
/dev/null | grep -q "nightly_routine.py"; then echo " ⋯ Cron job already exists, skipping" else # Add cron job (crontab -l 2>/dev/null; echo "${CRON_SCHEDULE} ${CRON_CMD}") | crontab - echo " ✓ Cron job added: ${CRON_SCHEDULE}" fi ``` The resulting command is configured earlier as: ```bash CRON_SCHEDULE="0 2 * * *" # 2:00 AM daily CRON_CMD="python3 ${SCRIPT_DIR}/nightly_routine.py >> ${LOG_DIR}/cron.log 2>&1" ``` ### Technical Analysis The setup script modifies the current user's crontab by default. This creates cross-session persistence and causes code in the project directory to execute unattended every day at 02:00. Scheduling is relevant to the declared nightly automation functionality, and the script does not request root privileges. However, installing persistence by default exceeds the minimum privileges required merely to initialize and test the Skill. The safer design would make persistent scheduling an explicit opt-in operation. The cron entry executes a mutable script from the installation directory without checking its ownership, permissions, hash, signature, or release version. Consequently, any process or account able to alter `nightly_routine.py`, `self_audit.py`, `memory_compact.py`, or `prompt_evolve.py` can turn the legitimate scheduled task into a recurring execution mechanism. The duplicate check is also imprecise: it searches for any entry containing `nightly_routine.py`, rather than matching the exact command managed by this project. This can prevent installation when an unrelated entry exists and does not provide a reliable basis for safe removal. ### Attack Path 1. A user runs `scripts/setup.sh` without the `--skip-cron` option. 2. The script adds a daily cron entry to the ...[truncated 921 chars]- Remediation
View remediation
