2 Commits

Include renames

Author	SHA1	Message	Date
BaaRai	ca15063db7	fix(intercept): match block rules on the declared targets before any lookup ... The target gate resolved each name through the cache before it matched the asset block rules, so a call to a name that a name rule blocks still cost a DNS lookup, and that query reached the name servers of the blocked domain. URL rules (exact_url, fuzzy_url) were not evaluated at dispatch at all: the gate passed no URL to the matcher, so they only applied to asset and intent writes. targetCheck.run now decides in this order, for a gated call: 1. URL rules, once per decision, on the URLs the call declares, as written. 2. Every block rule on the declared form of every target: the name as written, the IP literal, the range. 3. Only then resolution (names a derived exemption covers are still never resolved), and the block rules again on the resolved addresses. 4. Exemptions, pins and requests, unchanged. A hit in 1 or 2 blocks with TARGET_RULE_BLOCKED and the same decided row as any block, costs no lookup for any target of the call, and opens no request. - intercept.extractDeclared returns the targets (ExtractTargets is now a thin wrapper, unchanged for its callers) and the URLs that name a target: the WebFetch url, and every URL token the command-string rules read in Bash, shell_open, Monitor, shell_send and the string leaves of other tools, including ExecuteExtraTool's inner call. - The custom http tool's rendered URL and the URLs of a rendered command go to the same URL rules (gateRendered takes the URLs). - Known limit, stated in the comments next to the matcher (db.matchOne) and at the dispatch match: URL rules match the declared string. exact_url misses any other spelling (case, percent-encoding, trailing slash, added query, /./), fuzzy_url misses an encoded substring, and a command can build its URL at run time. For a host, a domain, IP or CIDR rule is the one to write. Unchanged: a tool-rule or judge deny still blocks before the gate is reached (no extraction, no lookup, no request); asset block rules still win over an allow and an ask; the gate off path does nothing; scripts stay advisory. Tests: - intercept: TestBlockRuleOnDeclaredNameNeedsNoLookup (exact_domain and fuzzy_domain; zero lookups, also for an unblocked name earlier in the same call), TestExtractDeclaredURLs, TestURLBlockRuleAtDispatch (WebFetch, Bash, MCP, ExecuteExtraTool, a pinned and an exempt host, a disabled rule, the rendered URL and command; zero lookups), TestExactURLRuleMatchesOnlyAsWritten (documents the limit). - guard: TestBlockRuleWinsOverAllowAndAsk (name rule and URL rule, each over a rule allow, judge allow, rule ask and judge ask, real interceptor: blocked, no allow row, nobody asked, zero lookups). TestDenyRuleWinsBeforeTargetRequest now also covers a judge deny and asserts zero lookups with the real gate. - server: TestBypass_CustomScriptToolTargetNotGated documents that a script tool's target, written in its stored code, is not visible to the gate: in a gated task the call is allowed and reaches the target with no lookup, no request and no row.	2026-11-11 15:47:58 +01:00
BaaRai	c0b741bcf6	feat(intercept): gate the rendered targets of custom tools (S3b 1.8) ... The hook reads the parameters of a custom tool call, not the URL or the command they render, and not a target written in the template itself. The custom command and http tools now run the target gate inside the tool, on what they are about to run, before anything is sent or started. Gate off (the default) is unchanged: with no scope or the flag off nothing is parsed, resolved, read or written. - intercept.GateRenderedURL: the target is read as net/http dials it (host of the parsed URL, explicit port, else the scheme default), then goes through the same decision as at the hook (asset block rules, exemptions, resolution, pin lookup) and the same request-and-wait, at most three passes. A URL whose target cannot be read is blocked with TARGET_GATE_UNAVAILABLE and logged as a decided row; no request, no lookup. - intercept.GateRenderedCommand: the rendered command is read with the command-string rules of Bash, and so is the rendering without the shell quoting of the parameters (a quoted parameter inside a host name hides the name from the rules). A command that names no target passes, as in Bash. - A gated scope without the interceptor that owns the gate blocks (TARGET_GATE_UNAVAILABLE), it never lets the call through. - runCommandTool and runHTTPTool take the tool key, which names the request rows. The gate runs before the tool's own timeout starts. - guard.TargetBlockMessage (was targetBlockMessage) is exported so the tools return the same model-facing text as the hook. - Unchanged: the script tool (its target is in stored code; advisory, D9), the custom-tool test endpoint (no scope: the operator's own action, D14), the hook order (a rule or judge deny blocks first; the tool then never runs, so its rendered target is never read), the evaluation of asset rules. Tests: TestRendered* in intercept (no database); in server, against PostgreSQL: TestCustomHTTPRenderedTargetGated, TestCustomCommandRenderedTargetGated, TestCustomToolTestEndpointUngated, TestTargetGateEndToEnd (a scripted worker's WebFetch waits, a click pins, the next call passes, revoke, it asks again), TestDenyRuleWinsBeforeRenderedTarget and TestGateOffTaskIsUnchanged. Not in this change: redirect targets of WebFetch and of the custom http tool (1.9).	2026-11-11 15:04:42 +01:00