Is bharathjanumpally/claw-permission-firewall safe?

The skill repository contains a .clawhub/lock.json file at its root that declares 'academic-research-hub' version 0.1.0 as a pre-installed dependency (installedAt: 1770957475341). This file is not referenced by package.json and represents an out-of-band dependency declaration specific to the Claw package manager. If the Claw PM honors lock files from installed skills, this would silently install 'academic-research-hub' alongside this firewall skill without any user-visible indication. This pattern — bundling a hidden companion skill inside a security tool — is a classic supply chain staging technique.

The .clawhub/lock.json file is checked into the skill repository rather than being a local developer artifact. Its presence in the distributed package means every installation of claw-permission-firewall carries this dependency declaration. Whether or not the Claw PM currently processes lock files from sub-skills, the file's presence is an unambiguous attempt to declare a runtime dependency on a second, separately-maintained skill whose security posture has not been evaluated in this audit.

The _meta.json file declares the canonical commit URL as 'https://github.com/clawdbot/skills/commit/f2156b72bfdd52bdf5189d6832a80191ab1b833d' but the skill was fetched from 'https://github.com/openclaw/skills'. This discrepancy means the stated commit cannot be used to verify the installed content and indicates the skill was either copied between organizations without metadata updates, or the metadata was deliberately set to reference an unverifiable provenance.

The bundled policy.yaml defines a 'permissive' mode with requireConfirmationAboveRisk: 0.75. Any action with a computed risk score below 0.75 — including connections to non-allowlisted domains (risk += 0.4), file writes outside the allow glob (risk += 0.35+0.15), and HTTP DELETE methods (risk += 0.35) — receives automatic ALLOW in permissive mode. An agent or skill that constructs the input object and specifies context.mode='permissive' can bypass the majority of protections this firewall claims to offer.

The connection diff shows 127.0.0.1:18790 and [::1]:18790 listening by process 'openclaw-gatewa' (PID 1083) appeared in the post-install snapshot but not the pre-install snapshot. PID 1083 is a low process number suggesting it was started early in the boot sequence as Oathe infrastructure, not by the skill. However, the listener's presence only in the post-install state cannot be fully explained from audit evidence alone.

The policy.yaml file is loaded with fs.readFileSync and parsed with js-yaml without any checksum, signature, or tamper-detection. An attacker who can write to the skill directory (e.g., through a directory traversal in another skill) could replace policy.yaml with a permissive variant that allows all actions, silently disabling the firewall while appearing to be active.

Auditd PATH records show canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .gcloud credentials) accessed at timestamps 1771906995 (pre-install baseline), 1771907004 (mid-session), and 1771907012 (post-install integrity check). All accesses are read-only (no WRITE/CREATE audit events), all six files accessed within a single millisecond at 1771907012 confirming batch Oathe verification, and the canary integrity report confirms no modifications.

All seven source files (index.ts, evaluate.ts, policy.ts, normalize.ts, redact.ts, match.ts, risk.ts, audit.ts) implement a coherent, readable firewall pipeline. No obfuscated code, no dynamic require/import of external URLs, no eval() calls, no base64-encoded payloads, and no use of child_process or network APIs.