T05 · Unauthorized Access and Privilege Escalation
- Location
README.md:81- Finding
Root systemd service executes a user-writable script
- Content
View full analysis
Vulnerability Details
File Location:
README.md, lines 81-98
Vulnerability Type: Local privilege escalation through an unsafe systemd service configuration
Risk Level: HighVulnerable Code
ini [Unit] Description=OpenClaw Gateway Watchdog After=network.target [Service] Type=simple ExecStart=/bin/bash /home/<user>/.openclaw/scripts/gateway-watchdog.sh Restart=always [Install] WantedBy=multi-user.targetbash sudo systemctl daemon-reload sudo systemctl enable --now openclaw-watchdogTechnical Analysis
The documented systemd unit does not specify a
User=orGroup=directive. A system-level service installed under/etc/systemd/systemtherefore runs as root by default.At the same time,
ExecStartpoints to a script under a regular user's home directory:text /home/<user>/.openclaw/scripts/gateway-watchdog.shThe installation script copies this file into the user's directory, where it ordinarily remains writable by that user. This creates a privilege-boundary violation: privileged systemd executes code controlled by an unprivileged account.
Continuous service registration is relevant to the declared watchdog functionality, but root execution is unnecessary. The watchdog only needs to make a local HTTP request, write user-scoped logs and a lock file, invoke OpenClaw, and send notifications.
Attack Path
- An administrator follows the documented instructions and creates the system-level unit in
/etc/systemd/system/openclaw-watchdog.service. - The administrator enables the unit with
sudo systemctl enable --now openclaw-watchdog. - Because the unit has no
User=directive, systemd runs it as root. - The owner of
/home/<user>/.openclaw/scripts/gateway-watchdog.sh, or an attacker who compromises that account, modifies the script to include arbitrary commands. - The service is restarted, crashes and is automatically restarted, or starts during a subsequent boot.
- systemd execu ...[truncated 674 chars]
- An administrator follows the documented instructions and creates the system-level unit in
- Remediation
View remediation
Remediation Suggestions
- Run the service as a dedicated, unprivileged account:
ini [Service] Type=simple User=openclaw-watchdog Group=openclaw-watchdog ExecStart=/usr/local/lib/openclaw-maintenance/gateway-watchdog.sh Restart=always NoNewPrivileges=true- Install executable service code in a root-owned directory rather than a user's home directory:
bash sudo install -d -o root -g root -m 0755 /usr/local/lib/openclaw-maintenance sudo install -o root -g root -m 0755 \ gateway-watchdog.sh \ /usr/local/lib/openclaw-maintenance/gateway-watchdog.sh-
Ensure the dedicated service account and other unprivileged users cannot modify the script, its parent directory, or the systemd unit.
-
Grant only the narrowly scoped permission required to restart the Gateway. Prefer a user-scoped OpenClaw service. If elevated control is unavoidable, use a tightly constrained privileged helper or sudoers rule for one fixed command instead of running the entire watchdog as root.
-
Add applicable systemd hardening directives, for example:
ini NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ProtectHome=true ProtectKernelTunables=true ProtectKernelModules=true ProtectControlGroups=true RestrictSUIDSGID=true LockPersonality=true ReadWritePaths=/var/log/openclaw-watchdog /run/openclaw-watchdog-
Document ownership and permission requirements and verify them before enabling the service. Refuse startup if the executable or its parent directories are writable by the service user or unrelated accounts.
-
After changing the unit, reload systemd and inspect the effective identity and security posture:
bash sudo systemctl daemon-reload sudo systemctl restart openclaw-watchdog systemctl show openclaw-watchdog -p User -p Group systemd-analyze security openclaw-watchdog.service
