On a Linux jump host that only executes signed files, why does a user-shell foothold barely feel it?

## The same control, a harsher environment A jump host built to be minimal is the natural place to try execution allowlisting on Linux. The mechanism differs from the Windows form in surface but not in kind: packages are installed only from signed repositories, and kernel-enforced integrity checking verifies a signature or a recorded hash when a file is executed. The unit of control is still **a file, judged at exec**. The environment then does something Windows does not do so bluntly: it hands the operator the interpreter as a first-class citizen. On the Windows workstation the script host is one approved component among many, and you can at least argue about denying it to a population. On the jump host, the shell **is the product**. Removing it removes the machine's purpose. ## Why the payload is never judged Executing a program is a specific operation: the kernel is asked to load an image, and that is where an integrity check hangs. Interpreting a script is not that operation. The shell is loaded once - approved, signed, verified - and after that it reads text. Whether the text arrives as a file it opens with ordinary read permissions, as a heredoc, or on standard input makes no difference: from the kernel's point of view no new program was ever launched. The signature machinery is not bypassed; it is **not on the path**. The same reasoning explains a control people routinely over-trust. Mounting a writable filesystem `noexec` prevents files on it from being executed as programs. It does not prevent an approved interpreter from opening a file on that filesystem and interpreting its contents, because that is a read, not an exec. Both controls are correct about files and silent about text. ## What the shell actually gives an operator It is worth being concrete about why this matters more than it looks. A shell is not a launcher, it is a language: conditionals, loops, variables, redirection, arithmetic, and the ability to compose every other approved binary on the image into a pipeline. Add whatever general-purpose language runtimes the host's own tooling depends on, and the approved file set is already a programming environment. An operator who never writes a byte to disk in executable form still has one. ## What bites instead The controls that remove options here all narrow the **interpreter or the identity**, not the file set: - **A restricted shell or a fixed command set.** If the role is `connect onward to three hosts`, the account gets something that can do that and nothing else. This is the direct analogue of a constrained language mode: the interpreter still exists, its generality does not. - **Removing runtimes the role does not need.** Every general-purpose language runtime left on the image is another interpreter with its own argument surface. Uninstalling one is a file decision, and unlike tightening rule types it genuinely removes something, because the file is now absent rather than approved. - **Cutting what the account may reach.** Approved commands compose into exactly as much as the identity running them is allowed to touch. The same shell in a role with no onward credentials and no write access to shared paths is worth much less. - **Making the host disposable.** A jump host rebuilt on a schedule turns a foothold with no persistence into a wasting asset, which is a different kind of removal: not of the capability, but of the time to use it. ## The honest summary Signature-based execution control on a Linux host is a real control with a clearly stated scope: it removes the move `bring a compiled tool and run it`. That is worth having. It does not remove `use the language that is already installed and approved`, and on a host whose reason to exist is an interactive shell, that second sentence covers most of what a foothold in user context can do anyway.