Why won't publisher or hash rules stop a script run by an already-allowlisted signed script host?

## The wrong answer, stated fairly A competent senior engineer looks at a locked-down back-office workstation where an intruder ran a script through the approved script host and says: *our path rules are too loose, move the estate to publisher and hash rules and this closes.* It is a reasonable-sounding answer. It is wrong, and knowing exactly why is the point of this leaf. ## Why tightening the rule type is null here Path, publisher and hash are three vocabularies for naming **one object: a file**. Each rule resolves the same question at the same moment - *may this file be loaded and run* - and differs only in how precisely it identifies the file and how much maintenance that precision costs. Now apply all three to this case. The script host is: - inside the system directory, so it satisfies a path rule; - signed by the platform vendor with a valid chain, so it satisfies a publisher rule; - the exact patched build the estate approved, so it satisfies a hash rule. The tightest possible rule set still says allow, and it says allow **correctly**. This binary is not a smuggled artefact; it is a component the estate needs, allowlisted deliberately. And the payload never reaches the rule set at all. The script is text: read from a file the interpreter opens as data, or from standard input, or passed inline. It is not presented to the operating system as an image to load, so the evaluation that would apply a rule is never triggered. **Nothing was allowed, because nothing was asked.** Tightening a decision that is never made cannot improve it. ## The general shape The same structure repeats across the estate wherever the approved software includes something that interprets: | The permitted file | What it is handed | What the rule set sees | | --- | --- | --- | | A signed script host | script text | one approved binary loading | | A document application | a macro inside a document | one approved binary loading | | A runtime that executes source | a source file as data | one approved binary loading | In each row the unit of control and the unit of attack have come apart. The rule set counts files; the operator is spending arguments. ## What actually removes the option The control that bites is one that constrains **what a permitted interpreter may be handed, or what it may do with it**: - **A constrained language mode.** When application control is enforced on Windows, the built-in script host can be dropped into a restricted mode where scripts may call approved commands but may not instantiate arbitrary platform types or call arbitrary APIs directly. The interpreter still runs; the capable subset of the language is gone. This is the canonical example of a control whose unit is capability rather than file identity. - **Signed macro projects, or no macro runtime at all.** Requiring macro code to carry an approved publisher's signature moves the check onto the content. Removing the runtime for the population that never writes macros removes the interpreter itself. - **Denying the interpreter to a population.** A back-office workstation whose role is a browser and a line-of-business application does not need a general scripting engine. Denying the script host to that group is a file rule, and here it works - because now the interpreter itself is the file being judged. That last bullet is worth dwelling on, because it shows the boundary is not `file rules are useless`. File rules work when the thing you want gone is a file you can refuse. They are null when the thing you want gone is generality inside a file you must keep. ## The residual, stated honestly A constrained mode does not delete the technique; it deletes the capable part of it. Allowed commands still compose into useful work for an operator, and every other permitted interpreter in the image is a separate decision with its own answer. So the honest position after this hardening is: *we removed bring-your-own-binary with the allowlist, and we removed the capable subset of one interpreter with the language mode. We still own an inventory question - which permitted programs on this image interpret, and what each of them may be handed.* ## The sentence that wins the question *All three rule types answer `may this file run`, the technique never presents a new file, so tightening the rule type changes nothing. The control that bites constrains what a permitted interpreter may be handed.*