diff --git a/skills/openclaw-system-admin/SKILL.md b/skills/openclaw-system-admin/SKILL.md deleted file mode 100644 index 8fab419eaa..0000000000 --- a/skills/openclaw-system-admin/SKILL.md +++ /dev/null @@ -1,203 +0,0 @@ ---- -name: openclaw-system-admin -description: Host security hardening and risk-tolerance configuration for OpenClaw deployments. Use when a user asks for security audits, firewall/SSH/update hardening, risk posture, exposure review, OpenClaw cron scheduling for periodic checks, or version status checks on a machine running OpenClaw (laptop, workstation, Pi, VPS). ---- - -# OpenClaw Host Hardening - -## Overview - -Assess and harden the host running OpenClaw, then align it to a user-defined risk tolerance without breaking access. Use OpenClaw security tooling as a first-class signal, but treat OS hardening as a separate, explicit set of steps. - -## Core rules - -- Recommend running this skill with a state-of-the-art model (e.g., Opus 4.5, GPT 5.2+). The agent should self-check the current model and suggest switching if below that level; do not block execution. -- Require explicit approval before any state-changing action. -- Do not modify remote access settings without confirming how the user connects. -- Prefer reversible, staged changes with a rollback plan. -- Never claim OpenClaw changes the host firewall, SSH, or OS updates; it does not. -- If role/identity is unknown, provide recommendations only. -- Formatting: every set of user choices must be numbered so the user can reply with a single digit. -- Ensure backups are enabled. Ask the user what backup system they use, check status, and (with explicit approval) offer to enable or configure backups appropriate to the OS. - -## Workflow (follow in order) - -### 1) Establish context (read-only) - -Try to infer 1–5 from the environment before asking. Prefer simple, non-technical questions if you need confirmation. - -Determine (in order): -1) OS and version (Linux/macOS/Windows), container vs host. -2) Privilege level (root/admin vs user). -3) Access path (local console, SSH, RDP, tailnet). -4) Network exposure (public IP, reverse proxy, tunnel). -5) OpenClaw gateway status and bind address. -6) Backup system and status (e.g., Time Machine, system images, snapshots). -7) Deployment context (local mac app, headless gateway host, remote gateway, container/CI). -8) Disk encryption status (FileVault/LUKS/BitLocker). -9) OS automatic security updates status. - Note: these are not blocking items, but are highly recommended, especially if OpenClaw can access sensitive data. - -If you must ask, use non-technical prompts (numbered): -1) “Are you using a Mac, Windows PC, or Linux?” -2) “Are you logged in directly on the machine, or connecting from another computer?” -3) “Is this machine reachable from the public internet, or only on your home/network?” -4) “Do you have backups enabled (e.g., Time Machine), and are they current?” -5) “Is disk encryption turned on (FileVault/BitLocker/LUKS)?” -6) “Are automatic security updates enabled?” - -Only ask for the risk profile after system context is known. - -If the user grants read-only permission, run the OS-appropriate checks by default. If not, offer them (numbered). Examples: -1) OS: `uname -a`, `sw_vers`, `cat /etc/os-release`. -2) Listening ports: - - Linux: `ss -ltnup` (or `ss -ltnp` if `-u` unsupported). - - macOS: `lsof -nP -iTCP -sTCP:LISTEN`. -3) Firewall status: - - Linux: `ufw status`, `firewall-cmd --state`, `nft list ruleset` (pick what is installed). - - macOS: `/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` and `pfctl -s info`. -4) Backups (macOS): `tmutil status` (if Time Machine is used). - -### 2) Run OpenClaw security audits (read-only) - -If the user grants permission, run `openclaw security audit --deep` by default. If they decline or ask for alternatives, offer these options (numbered): -1) `openclaw security audit --deep` (best-effort live gateway probe; default) -2) `openclaw security audit` (faster, non-probing) -3) `openclaw security audit --json` (structured output) - -Offer to apply OpenClaw safe defaults (numbered): -1) `openclaw security audit --fix` - -Be explicit that `--fix` only tightens OpenClaw defaults and file permissions. It does not change host firewall, SSH, or OS update policies. - -If browser control is enabled, recommend that 2FA be enabled on all important accounts, with hardware keys preferred and SMS not sufficient. - -### 3) Check OpenClaw version/update status (read-only) - -If the user grants permission, run `openclaw update status` by default. Otherwise, offer it (numbered): -1) `openclaw update status` - -Report the current channel and whether an update is available. - -### 4) Determine risk tolerance (after system context) - -Ask the user to pick or confirm a risk posture and any required open services/ports (numbered choices below). -Do not pigeonhole into fixed profiles; if the user prefers, capture requirements instead of choosing a profile. -Offer suggested profiles as optional defaults (numbered). Note that most users pick Home/Workstation Balanced: -1) Home/Workstation Balanced (most common): firewall on with reasonable defaults, remote access restricted to LAN or tailnet. -2) VPS Hardened: deny-by-default inbound firewall, minimal open ports, key-only SSH, no root login, automatic security updates. -3) Developer Convenience: more local services allowed, explicit exposure warnings, still audited. -4) Custom: user-defined constraints (services, exposure, update cadence, access methods). - -### 5) Produce a remediation plan - -Provide a plan that includes: -- Target profile -- Current posture summary -- Gaps vs target -- Step-by-step remediation with exact commands -- Access-preservation strategy and rollback -- Risks and potential lockout scenarios -- Least-privilege notes (e.g., avoid admin usage, tighten ownership/permissions where safe) -- Credential hygiene notes (location of OpenClaw creds, prefer disk encryption) - -Always show the plan before any changes. - -### 6) Offer execution options - -Offer one of these choices (numbered so users can reply with a single digit): -1) Do it for me (guided, step-by-step approvals) -2) Show plan only -3) Fix only critical issues -4) Export commands for later - -### 7) Execute with confirmations - -For each step: -- Show the exact command -- Explain impact and rollback -- Confirm access will remain available -- Stop on unexpected output and ask for guidance - -### 8) Verify and report - -Re-check: -- Firewall status -- Listening ports -- Remote access still works -- OpenClaw security audit (re-run) - -Deliver a final posture report and note any deferred items. - -## Required confirmations (always) - -Require explicit approval for: -- Firewall rule changes -- Opening/closing ports -- SSH/RDP configuration changes -- Installing/removing packages -- Enabling/disabling services -- User/group modifications -- Scheduling tasks or startup persistence -- Update policy changes -- Access to sensitive files or credentials - -If unsure, ask. - -## Periodic checks - -After OpenClaw install or first hardening pass, run at least one baseline audit and version check: -- `openclaw security audit` -- `openclaw security audit --deep` -- `openclaw update status` - -Ongoing monitoring is recommended. Use the OpenClaw cron tool/CLI to schedule periodic audits (Gateway scheduler). Do not create scheduled tasks without explicit approval. Store outputs in a user-approved location and avoid secrets in logs. -When scheduling headless cron runs, include a note in the output that instructs the user to call `openclaw-system-admin` so issues can be fixed. - -### Required prompt to schedule (always) - -After any audit or hardening pass, explicitly offer scheduling and require a direct response. Use a short prompt like (numbered): -1) “Do you want me to schedule periodic audits (e.g., daily/weekly) via `openclaw cron add`?” - -If the user says yes, ask for: -- cadence (daily/weekly), preferred time window, and output location -- whether to also schedule `openclaw update status` - -Also offer a periodic version check so the user can decide when to update (numbered): -1) `openclaw update status` (preferred for source checkouts and channels) -2) `npm view openclaw version` (published npm version) - -## OpenClaw command accuracy - -Use only supported commands and flags: -- `openclaw security audit [--deep] [--fix] [--json]` -- `openclaw status` / `openclaw status --deep` -- `openclaw health --json` -- `openclaw update status` -- `openclaw cron add|list|runs|run` - -Do not invent CLI flags or imply OpenClaw enforces host firewall/SSH policies. - -## Logging and audit trail - -Record: -- Gateway identity and role -- Plan ID and timestamp -- Approved steps and exact commands -- Exit codes and files modified (best effort) - -Redact secrets. Never log tokens or full credential contents. - -## Memory writes (required) - -Follow the durable-memory prompt format used by OpenClaw compaction: -- Write lasting notes to `memory/YYYY-MM-DD.md`. - -After each audit/hardening run, append a short, dated summary to `memory/YYYY-MM-DD.md` -(what was checked, key findings, actions taken, any scheduled cron jobs, key decisions, -and all commands executed). Append-only: never overwrite existing entries. -If there are durable preferences or decisions (risk posture, allowed ports, update policy), -also update `MEMORY.md` (long-term memory is optional and only used in private sessions). - -If the session cannot write to the workspace, ask for permission or provide exact entries -the user can paste into the memory files.