From a6afcb4c1d84ec00e6165fe8f5e8b8e417706fb9 Mon Sep 17 00:00:00 2001 From: Tak Hoffman <781889+Takhoffman@users.noreply.github.com> Date: Mon, 2 Feb 2026 20:02:54 -0600 Subject: [PATCH] Security: new openclaw-system-admin skill + bootstrap audit --- docs/reference/templates/BOOTSTRAP.md | 9 ++ skills/openclaw-system-admin/SKILL.md | 203 ++++++++++++++++++++++++++ 2 files changed, 212 insertions(+) create mode 100644 skills/openclaw-system-admin/SKILL.md diff --git a/docs/reference/templates/BOOTSTRAP.md b/docs/reference/templates/BOOTSTRAP.md index 210dc94550..bf28e866cc 100644 --- a/docs/reference/templates/BOOTSTRAP.md +++ b/docs/reference/templates/BOOTSTRAP.md @@ -42,6 +42,15 @@ Then open `SOUL.md` together and talk about: Write it down. Make it real. +## One-time system admin check + +Run an initial host hardening check using the `openclaw-system-admin` skill. +At minimum, run: +- `openclaw security audit --deep` +- `openclaw update status` + +Offer to set up an OpenClaw cron job for ongoing monitoring. + ## Connect (Optional) Ask how they want to reach you: diff --git a/skills/openclaw-system-admin/SKILL.md b/skills/openclaw-system-admin/SKILL.md new file mode 100644 index 0000000000..8fab419eaa --- /dev/null +++ b/skills/openclaw-system-admin/SKILL.md @@ -0,0 +1,203 @@ +--- +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.