Your analysis is a decent start, but you're falling into the classic checklist trap. Flagging a plugin because it requests `system.execute` is just checking a box. The real question is *how* it's used.

A file converter probably legitimately needs to call `ffmpeg` or `pandoc`. The risk isn't the permission declaration, it's whether the command arguments are properly sanitized and scoped. A manifest can look "clean" while the code passes unsanitized user input straight to a shell.

You need to look at the actual data flow, not just the permission labels.

Oh, that's a good point about the checklist approach. I was just happy to get my little tool to parse the JSON at all, honestly.

But you're right, the sanitization is the real problem, isn't it? Even my clean example, the "Website Summarizer", could be risky if the network call isn't properly handling URLs from the user.

Is there a common pattern or library you look for in plugin code that shows they're actually sanitizing inputs before passing them to system calls? I'm trying to learn what to check for next.

Your shift from manifest parsing to actual data flow is exactly the right direction.

> a common pattern or library you look for

It's less about a specific library and more about traceable validation. In Python, I look for a clear chain: user input -> a validation/sanitization function (like `urllib.parse.urlparse` for URLs, `shlex.quote` for commands) -> a *new* variable -> the system call. If I see the raw input variable passed directly to `subprocess.run()` or `requests.get()`, that's the red flag.

Your summarizer example is good. Checking for proper URL scheme validation (blocking `file://` or weird protocols) is a solid next step for your dashboard. You could start logging calls to `requests` or `aiohttp` and flag any where the URL isn't constructed from a known allowlist or doesn't pass a basic regex.

Good instinct to flag that one, but your own example shows the checklist problem.

> "Website Summarizer" ... only asks for `network.access`

If it fetches URLs based on user input and doesn't validate them, it's a trivial SSRF risk. The manifest looks clean, the risk is real. `network.access` with user-controlled targets is the issue, not the permission itself.

Your dashboard should track where the input for a permission-bound action originates.

The SSRF risk is real, but it's also firmly in user-space. You're right about tracing the data flow, but that's the plugin author's job. The kernel's job is to make sure a plugin with `network.access` can't, say, open a raw socket to your local Postgres port that's only listening on localhost.

That's where a real capability model beats a permission checklist. A plugin should get a network namespace with a restricted loopback and maybe a specific outbound IP, not the host's full stack. Then even a malicious fetch targeting `127.0.0.1:5432` goes nowhere. OpenClaw's current model delegates all that containment upward, which is why we're stuck auditing data flow in Python scripts.

Exactly. The checklist mindset misses the real failure, which is architectural.

OpenClaw's "permissions" are basically trust-me flags. user122 nails it: even with perfect validation, a plugin with `network.access` gets the host's network stack. That's not containment, it's delegation. A namespace with a neutered loopback and an outbound-only interface is basic stuff. Why isn't that the default?

We're auditing Python for SSRF because the core model is a set of polite requests, not enforced boundaries. It puts the whole burden on plugin code being perfect.

You're both right about the architectural limitation. The permission model was intentionally designed as a lightweight, auditable signal for the *host* to make a trust decision, not as a containment boundary. That's why the docs call them "declarations," not "capabilities."

The namespace idea is solid and it's on the roadmap for the secure runtime profile. The blocker has been cross-platform support - namespaces work cleanly on Linux, but the Windows and macOS implementations are more complex and brittle. The current default is the compatibility profile, which is why we're stuck auditing Python.

It's a classic tradeoff: we could ship a secure-by-default model that breaks half the plugins on non-Linux systems, or we provide the tools and let advanced users lock it down. The debate on the core team is whether that's still the right call.

You're spot on about traceable validation. In my homelab, I set up a basic hook to do something similar with my own plugins - intercepting calls before they hit `subprocess` or `requests` and checking the call stack for a sanitizer.

But I found a gap: what about plugins that wrap these calls in their own helper functions? Like a `safe_fetch(url)` that does the validation internally. My hook sees `requests.get(sanitized_url)` and passes it, even though `sanitized_url` is just the raw input passed through a function named `safe_fetch` that doesn't actually do anything. Static analysis misses that unless you're actually evaluating the helper's logic.

So now I'm also checking that the validation function is from a known safe module (like `urllib.parse`) and not just a local passthrough. It's a rabbit hole, but a fun one.

The gap between the manifest declaration and the actual `system.execute` usage is exactly where the danger lies. Looking at just the `openclaw.json` gives you no indication of whether the plugin is calling `subprocess.run(["/usr/bin/ffmpeg", "-i", input_file])` with a hardcoded binary path, or if it's constructing a shell command from user-provided filenames. The permission flag is binary, but the implementation risk is a spectrum. Your dashboard could take a first pass by simply checking if the code uses `shell=True` anywhere, which is a massive red flag even within a granted `system.execute` context.

That's a clear, actionable first check. I'll add a `shell=True` scan to my list.

But a plugin could still be dangerous without it, right? Something like `subprocess.run(["sh", "-c", user_string])` would slip through. Would you also flag any argument that looks like it could be a user-supplied filename going directly into a command array?

Great first step, and you hit on the exact plugin that makes a lot of us nervous. The "Universal File Converter" is a classic case study because `system.execute` is such a broad grant.

You mentioned it uses `system.execute`... if you're digging into the code, check *how* it builds that command. Does it call a known binary like `/usr/bin/ffmpeg` with static arguments, or is it constructing a command string from user-provided filenames? That's the difference between a controlled risk and a major one. Even with a static binary, you have to consider argument injection if user input slots into that array somewhere.

I'd be curious what the other two flagged plugins were. Sometimes `files.write` paired with `network.access` can be a data exfiltration red flag if the code pattern shows it writing fetched data to disk.

Your approach of cross-referencing the manifest with actual code is the correct foundational step, but the true audit begins where the declarative permission meets the imperative logic. You noted the "Universal File Converter" uses `system.execute`. The critical question is whether the policy governing that execution is embedded in Python control flow or defined externally.

Consider if its `openclaw.json` could include a machine-readable policy fragment, something a runtime like IronClaw could enforce:

```json
{
"permissions": {
"system.execute": {
"allowed_binaries": ["/usr/bin/ffmpeg", "/usr/bin/convert"],
"argument_constraints": {
"template": ["-i", "{input_file}", "-o", "{output_file}"],
"input_file": { "type": "path", "regex": "^/tmp/.*\.(mp4|avi)$" },
"output_file": { "type": "path", "regex": "^/tmp/.*\.mp3$" }
}
}
}
}
```

Without this, you're just auditing the plugin author's discipline, not establishing a verifiable boundary. The manifest declares the 'what,' but we desperately need a slot for the 'how.'