What does an application-control rule naming a path, publisher or hash actually evaluate?
answer
- three ways to name one thing
- the unit of control is a file
- verdict fires at load, then stops
- arguments and script text are not files
- removes bring-your-own-binary only
basics
~20 sIt evaluates the identity of a file at the moment something tries to load and run it: where the file sits, who signed it, or its exact bytes. It says nothing about what an already-permitted program is later handed.
solid answer
~50 sAll three rule types answer one question at load time: may THIS FILE run on this host? A path rule matches where the file lives, a publisher rule matches the code-signing certificate it carries (optionally narrowed to product, file name or version), and a hash rule matches the exact bytes. The check fires when the operating system is asked to create a process or load a module from that file, and the verdict is allow or deny for that file. What none of the three states is what an allowed program may be handed once it is running: its arguments, the script text it reads, the document content a permitted application interprets. That is not a weakness of one rule type; it is the unit of control. Allowlisting removes `bring your own binary`, not `use what is already approved here`.
go deeper
Be ready to state the three rule types and the single question all of them answer: may this file be loaded and run. Say plainly that the check happens at load and covers file identity only.
An interviewer expects the maintenance tradeoff: hash rules break on every patch, publisher rules survive it, path rules break where users can write. Explain when the evaluation fires and when it stops being consulted.
Demonstrate that you know what the control genuinely removes in a real estate and what it leaves untouched, so you can say what residual you own after rolling it out rather than presenting it as a finished answer.
Own the framing for people who fund it: allowlisting buys the removal of one class of adversary move at a permanent maintenance cost, and the estate still needs a separate answer for permitted interpreters.
## What the rule is actually asked Application control, also called execution allowlisting, inverts the default of a general-purpose operating system. Normally any file a user can read and mark executable may run, and security is a matter of catching the bad ones. Under an allowlist the default is deny: a file runs only because some rule says it may. Every implementation of that idea expresses its rules in the same three currencies, and they differ only in **how they name a file**. - **Path** - the location. *Anything under the system directory may run.* Cheapest to write and to maintain, and it fails wherever a user can create or replace a file inside an allowed location. - **Publisher** - the code-signing certificate the file carries, optionally narrowed to a product name, an original file name, or a minimum version. *Anything signed by this vendor may run.* This is what real estates are built on, because a patched build keeps its signer and keeps running. - **Hash** - the exact bytes. *This one build of this one file may run.* Precise and effectively unmaintainable at scale: every patch invalidates the rule. The operational argument between these three is real, and a candidate should be able to have it. But it is an argument about **maintenance cost and precision**, not about scope. All three answer the identical question. ## When the check happens, and when it stops Evaluation happens at load: process creation, and module or library load. Stronger configurations also present script files and installer packages to the same rule set before their host is allowed to run them. The verdict is per file, and it is final for that file. Once the answer is allow, **the rule set has finished**. It is not consulted again for anything that file goes on to do: not for the arguments it receives, not for the network it opens, not for the child processes it starts unless those children are themselves new files being loaded. That boundary is the whole subject. A program is a file; a program's input is not. ## What that leaves uncovered Three cases follow directly, and they are the ones interviewers push on: 1. **A permitted interpreter.** A script host, a shell, a runtime that executes source is an approved, signed file. The script it interprets is data handed to an allowed program. No new file is presented for judgment, so no rule is consulted. 2. **A macro runtime inside a permitted application.** A document viewer or spreadsheet application is approved. The macro lives inside a document, which is content, not an executable presented at load. 3. **An argument no rule states.** Rules name files. They do not name command lines. Two invocations of the same approved binary, one routine and one hostile, are indistinguishable to a rule set whose vocabulary is file identity. ## What it does buy, which is not nothing Stated honestly, a default-deny allowlist removes an entire class of moves: dropping a compiled tool into a user-writable directory and running it, running an unsigned build of anything, running a renamed binary from a temp folder, installing something the estate never approved. For an operator whose next step was `write a file and execute it`, the estate is now expensive. For an operator whose next step is `hand an approved program some text`, the estate has not moved at all. ## Saying it in an interview The crisp formulation is: *path, publisher and hash are three ways of naming a file, and the rule set only ever decides whether a named file may load.* Follow it with the consequence - that anything already permitted keeps whatever generality it had - and you have given the whole answer at this level without reciting a product's feature list.
- Why do mature estates build on publisher rules rather than hash rules?Because a hash rule names one exact build and dies at the next patch, so a hash-based estate needs a rule change for every update of every approved file. A publisher rule survives patching, since the new build carries the same signer. The tradeoff is precision: a publisher rule admits every current and future file that vendor signs, including ones the estate never evaluated.
- Where does a path rule fail on its own terms, without any interpreter involved?Wherever a low-privilege user can write inside an allowed location. If any directory under an allowed path is user-writable, a newly created file satisfies the rule and runs. That is a genuine defect of the rule type and it is fixed by tightening the rule - which is exactly what does not help against a permitted interpreter, because there no new file is created at all.
- Does application control apply to code that never becomes a file on disk?Not through these rules. The evaluation is triggered by a load of a file, so code that is generated and executed inside an already-permitted process is outside the rule set's vocabulary entirely. Constraining that requires a control aimed at what the permitted process may do, not at which files may run.
A guest list at a door checks who may come in. It does not check what they carry in their pockets, or who telephones them once they are inside.
saying these in an interview costs you the question
- Says an allowlist controls what programs may do, not which may run
- Thinks hash rules are the strict version of the same scope
- Believes an allowlist inspects command lines
- Assumes scripts are covered because scripts are files
- Calls allowlisting a complete replacement for other controls