Under an unprivileged account, how can a process still gain privilege when it executes another program?

## The gap an unprivileged id leaves Declaring an unprivileged numeric id fixes the identity of the process the runtime starts. It does not say anything about the identity of programs that process goes on to execute, and that distinction is where the last gap in start-time hardening lives. Filesystems can mark a program file so that running it does not run as the caller. Two variants matter: - **Run as the file's owner rather than the caller.** A process running as id `10001` executes the file and the new program runs as the owner - id `0` if the build installed it. - **Grant a named extra power on execution.** The program starts holding one specific privileged capability that the caller did not have, without changing identity. On a general-purpose host this is a deliberate, useful feature: it is how an ordinary account changes its own password or runs a diagnostic that needs a privileged socket. Inside a workload image it is almost always residue - a package installed for one binary dragged in a handful of marked files nobody looked at. ## Why this matters after a compromise Put it in the chain an attacker actually walks. Code execution as an unprivileged id, in a container with a read-only root filesystem and an empty privilege set, is a poor position: nothing to write, no powers to use. But if the image ships one marked program file, executing it is a single step that restores identity or a power, and the rest of the hardening was built on the assumption that the process holds neither. The severity is not that the marked file is dangerous in itself; it is that it converts a contained compromise back into a privileged one **inside** the container, which is where the remaining boundary weaknesses become worth something. ## What the declaration does The spec can carry a flag that forbids a process from gaining privilege when it executes another program. Once set, three properties make it unusually valuable for its size: 1. **It is enforced by the kernel at every execution**, not by a scanner that ran at build time and may have missed a file. 2. **It is inherited by every child process** the workload starts, so a wrapper script, a spawned helper and anything they start are all covered. 3. **It cannot be removed from inside.** A process that has it cannot clear it for itself or its children, so a compromised process cannot simply turn it off before it starts the marked program. The practical effect is that a marked file still executes - it just executes as the caller, with the caller's powers, exactly as an unmarked one would. Nothing crashes the boundary; the elevation is silently declined. ## What it costs - **Any legitimate helper relying on the marking stops working.** In a workload image that is usually an argument for removing the helper, not for removing the flag. - **The failure is confusing the first time.** The program runs, and then fails at the specific operation that needed the privilege it did not get, which can look like an unrelated bug some way into the work. - **A supervisor that starts privileged and drops down** is incompatible with this shape in general. The container-native answer is to start as the target id directly and skip the supervisor. ## Defence in layers, in order | layer | what it does | what it misses on its own | |---|---|---| | build without marked files | removes the mechanism entirely | a later base-image update can reintroduce one | | scan the image for marked files | catches reintroduction at build time | only as current as the last scan | | forbid privilege gain at exec | declines the elevation at every execution | the marked file is still present in the image | | refuse specs lacking the flag at admission | makes it uniform across an estate | nothing, for this specific gap | They compose deliberately: the build removes the mechanism, the flag makes its reintroduction harmless, and the gate makes the flag non-optional. ## Why this is a differentiator rather than a basic Most candidates get as far as the unprivileged account and the read-only root filesystem, because those are visible: something breaks and you fix it. This one breaks nothing in a well-built image, so it is never forced on anyone's attention, and it defends a step in an escalation chain rather than an obvious asset. Naming it - and being able to say that it is inherited, kernel-enforced and irreversible from inside - is a reasonable signal that the candidate has hardened workloads rather than read a checklist.