Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

OpenClaw Guard

v1.1.0

配置文件修改守护脚本 - 危险操作前自动备份,一键回滚

0· 182·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Suspicious
View report →
OpenClawOpenClaw
Suspicious
medium confidence
!
Purpose & Capability
The name/description claim a local backup-and-rollback guard which is consistent with the provided guard.sh. However the code expects and invokes commands not declared in the metadata: systemctl, an openclaw CLI subcommand (openclaw message send), and optionally curl/nc. The script also contains a scripts/config/settings.yaml that enables Feishu notifications to a hard-coded Open ID by default (/home path and feishu_enabled: true). Requesting the ability to contact a remote collaborator via openclaw/Feishu is not documented in the skill metadata and is disproportionate to a pure local backup/rollback helper.
!
Instruction Scope
SKILL.md instructs users to run the included scripts and to modify AGENTS.md and crontab; the script backs up listed config files and may restart the Gateway. The runtime instructions and script also call external APIs/commands: openclaw message send (to deliver notifications), and health checks using curl/nc. The SKILL.md suggests backing '任何系统配置文件' in examples which broadens implied scope. The skill will read/write backup, PID, and log files under ~/.openclaw and may restart services — all expected — but the notification path forwards internal state to an external recipient by default, which is outside the documented local-safety scope.
Install Mechanism
There is no install spec (instruction-only) which minimizes installation footprint, but the bundle includes an executable script (scripts/guard.sh). No network downloads occur at install time, however running the script exercises system services and the openclaw CLI. No extra packages are downloaded by the skill itself.
!
Credentials
The metadata declares no required env vars or credentials, yet the script depends on $HOME, $WORKSPACE and uses a scripts/config/settings.yaml that hardcodes backup_dir (/home/ljj/...) and feishu_enabled: true with a specific feishu_open_id. The skill will attempt to send messages using 'openclaw message send' to that open id by default. That effectively exfiltrates backup/incident information to an external account unless the user changes the defaults — this is a mismatch between declared and actual required access.
Persistence & Privilege
always is false (normal). The script writes PID files, backups, logs to ~/.openclaw/backups and can restart user/system services via systemctl or the openclaw CLI. Those privileges are consistent with a rollback tool, but they are powerful (service restart, file overwrite). The combination of service-control privileges and default external notifications increases risk if defaults are not inspected.
What to consider before installing
What to check before installing/running: 1) Inspect and edit scripts/config/settings.yaml (the script loads this file by default). Immediately set feishu_enabled: false or replace feishu_open_id with your own trusted recipient. The provided file enables Feishu notifications to a specific Open ID by default — that will cause the script to send backup/incident info via the local 'openclaw' messaging integration. 2) Confirm you trust and have the 'openclaw' CLI and its message-sending behaviour; the script uses 'openclaw message send' rather than a local-only log, so it can transmit messages out of your environment. 3) Verify required tooling: systemctl (or systemctl --user), bash, and optionally curl/nc. The metadata did not list these; make sure these commands exist and that you understand the privileges they require (service restart). 4) Update backup paths: change hard-coded /home/ljj paths and BACKUP_DIR to directories you control so backups don't go to unexpected locations. 5) Run tests first: use ./scripts/guard.sh test and ./scripts/guard.sh start with a short timeout in a non-production environment to confirm behavior. Inspect the backup contents and incident_log.txt to ensure no sensitive secrets are included before enabling notifications. 6) Consider limiting scope: review and, if needed, trim BACKUP_FILES so only necessary files are backed up. The examples and README mention 'any system config file' which could be overly broad. 7) If you cannot audit the script or do not want any external notifications, do not install/run it or remove the notification/send code paths. If you want to proceed, mark the skill suspicious and change the defaults described above.

Like a lobster shell, security has layers — review code before you run it.

backupvk977sjy0c6wkfea73m84zfjh6s8310bmconfigvk977sjy0c6wkfea73m84zfjh6s8310bmlatestvk977sjy0c6wkfea73m84zfjh6s8310bmsafetyvk977sjy0c6wkfea73m84zfjh6s8310bm

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Comments