chore: fix formatting
parent
ac2b71f240
commit
7dfa99a6f7
|
|
@ -46,6 +46,7 @@ Write it down. Make it real.
|
|||
|
||||
Since this is a new install, run the recommended host healthcheck using the `healthcheck` skill.
|
||||
At minimum, run:
|
||||
|
||||
- `openclaw security audit --deep`
|
||||
- `openclaw update status`
|
||||
|
||||
|
|
|
|||
|
|
@ -31,21 +31,23 @@ Before starting, check the current model. If it is below state-of-the-art (e.g.,
|
|||
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.
|
||||
|
||||
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.
|
||||
10) Usage mode for a personal assistant with full access (local workstation vs headless/remote vs other).
|
||||
10. Usage mode for a personal assistant with full access (local workstation vs headless/remote vs other).
|
||||
|
||||
First ask once for permission to run read-only checks. If granted, run them by default and only ask questions for items you cannot infer or verify. Do not ask for information already visible in runtime or command output. Keep the permission ask as a single sentence, and list follow-up info needed as an unordered list (not numbered) unless you are presenting selectable choices.
|
||||
|
||||
If you must ask, use non-technical prompts:
|
||||
|
||||
- “Are you using a Mac, Windows PC, or Linux?”
|
||||
- “Are you logged in directly on the machine, or connecting from another computer?”
|
||||
- “Is this machine reachable from the public internet, or only on your home/network?”
|
||||
|
|
@ -53,30 +55,33 @@ If you must ask, use non-technical prompts:
|
|||
- “Is disk encryption turned on (FileVault/BitLocker/LUKS)?”
|
||||
- “Are automatic security updates enabled?”
|
||||
- “How do you use this machine?”
|
||||
1) Personal/workstation (mostly local dev)
|
||||
2) Headless server (always on, accessed remotely)
|
||||
3) Something else?
|
||||
1. Personal/workstation (mostly local dev)
|
||||
2. Headless server (always on, accessed remotely)
|
||||
3. Something else?
|
||||
|
||||
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:
|
||||
|
||||
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:
|
||||
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).
|
||||
4. Backups (macOS): `tmutil status` (if Time Machine is used).
|
||||
|
||||
### 2) Run OpenClaw security audits (read-only)
|
||||
|
||||
As part of the default read-only checks, run `openclaw security audit --deep` without a separate permission prompt. Only offer alternatives if the user requests them:
|
||||
1) `openclaw security audit` (faster, non-probing)
|
||||
2) `openclaw security audit --json` (structured output)
|
||||
|
||||
1. `openclaw security audit` (faster, non-probing)
|
||||
2. `openclaw security audit --json` (structured output)
|
||||
|
||||
Offer to apply OpenClaw safe defaults (numbered):
|
||||
1) `openclaw security audit --fix`
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -85,7 +90,8 @@ If browser control is enabled, recommend that 2FA be enabled on all important ac
|
|||
### 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`
|
||||
|
||||
1. `openclaw update status`
|
||||
|
||||
Report the current channel and whether an update is available.
|
||||
|
||||
|
|
@ -94,14 +100,16 @@ Report the current channel and whether an update is available.
|
|||
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).
|
||||
|
||||
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
|
||||
|
|
@ -116,14 +124,16 @@ 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
|
||||
|
||||
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
|
||||
|
|
@ -132,6 +142,7 @@ For each step:
|
|||
### 8) Verify and report
|
||||
|
||||
Re-check:
|
||||
|
||||
- Firewall status
|
||||
- Listening ports
|
||||
- Remote access still works
|
||||
|
|
@ -142,6 +153,7 @@ 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
|
||||
|
|
@ -157,6 +169,7 @@ 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`
|
||||
|
|
@ -167,19 +180,23 @@ When scheduling headless cron runs, include a note in the output that instructs
|
|||
### 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`?”
|
||||
|
||||
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)
|
||||
|
||||
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`
|
||||
|
|
@ -191,6 +208,7 @@ 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
|
||||
|
|
@ -201,6 +219,7 @@ 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`
|
||||
|
|
|
|||
Loading…
Reference in New Issue