Security Dashboard
ReviewAudited by ClawScan on May 10, 2026.
Overview
The dashboard mostly matches its security-monitoring purpose, but its installer creates a persistent service with broad passwordless sudo access that users should review carefully.
Review scripts/install.sh before running it with sudo. Prefer the dedicated user mode, keep the dashboard bound to 127.0.0.1, narrow the sudoers rules if possible, and avoid the root service option unless the server is trusted and isolated.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the dashboard process or service account is compromised, an attacker could read broad system status and log information as root-level commands permit.
The installer grants the dashboard user passwordless root-level execution of broad status and log commands. These are relevant to monitoring, but wildcard journalctl/ss access is broader than the narrow checks users may expect.
Cmnd_Alias DASHBOARD_CMDS = /usr/bin/systemctl is-active *, ... /usr/bin/journalctl *, /usr/bin/ss *, /usr/bin/tailscale status * openclaw-dashboard ALL=(ALL) NOPASSWD: DASHBOARD_CMDS
Restrict sudoers to the exact command arguments needed, avoid wildcard journalctl access, disable pagers, document every privileged command, and provide a clear uninstall path.
Opening or polling the dashboard causes the server to run local system commands to collect metrics.
The dashboard gathers metrics by executing local shell commands. The visible commands are hard-coded and purpose-aligned, but shell execution is still a sensitive implementation choice.
const { execSync } = require('child_process'); ... return execSync(cmd, { encoding: 'utf8', timeout: 5000 }).trim();Keep command inputs fixed, avoid user-controlled shell arguments, prefer safer APIs where practical, and ensure the service remains bound to localhost.
The dashboard will keep running after installation and restart on boot until the service is disabled or removed.
The installer enables and starts a long-running systemd service. Persistence is expected for a real-time dashboard, but users should notice it.
systemctl enable $SERVICE_NAME systemctl restart $SERVICE_NAME
Install only on intended servers, verify the service user and bind address, and document disable/uninstall commands.
Users may not see the privileged installation behavior or prerequisites from registry metadata alone.
The registry metadata does not reflect that the included artifacts contain an installer and Linux/systemd/Node-oriented runtime requirements.
Install specifications: No install spec — this is an instruction-only skill. ... Required binaries: none
Declare the install script, Linux/systemd requirement, Node requirement, and privileged command capabilities in metadata.