A root systemd timer runs a script writable by a deploy account — which adversary goal do you remove?
answer
- controls remove goals, not artefacts
- ask what the operator substitutes
- one goal has no alternative carrier
- writable parent directory equals writable file
- continuity has many carriers, the transition has one
basics
~10 sRemove the Privilege Escalation goal first: make nothing a lower-privileged account can write execute as root. That goal has no substitute. Persistence has many carriers, so blocking timers alone just relocates it.
solid answer
~50 sOne artefact, two goals, and they need different controls — so name the intent before naming a remedy. The Privilege Escalation goal is that a deploy account's write turns into root execution. Take the write away (root ownership of the script and every directory on its path, plus a root-only unit directory) and the goal is gone with no substitute available, because nothing else in the estate converts that account into root unless you left another such path. The Persistence goal is that execution returns after a reboot without re-authenticating, and the timer is only one carrier of it — cron, other units, user-level units and shell profiles all serve it. Blocking timers moves that goal rather than removing it; removing it means the whole scheduled-work surface is reconciled from a source of truth, so anything added by hand does not survive. Fix the escalation first: it is narrower, it has no substitute, and it is what makes the rest cheap for the operator.
go deeper
Know that a root-run script writable by a less-privileged account is a way to reach root, and that fixing ownership on the file alone is not enough if its directory is still writable.
Separate the two goals riding one artefact and explain the mechanics of each: the write-to-root-execution transition, and the return of execution after reboot without re-authenticating.
Reason about substitution explicitly. Say which goal the operator can re-carry elsewhere and which they cannot, and let that decide what you fix first rather than what is most visible.
Own the sequencing under a real budget: commit the narrow no-substitute fix now with a named owner, book the fleet-wide reconciliation as its own programme, and be able to defend spending on the smaller change first.
## Why the question has to be asked in this order A control removes a **goal**, not an artefact. When one artefact serves two goals, deleting it feels like progress and usually is not, because the operator only loses whichever goals had no other carrier. So the architect's sequence is: name the goals, ask for each one what the operator would substitute if it were unavailable, and spend on the goal with no substitute. Here the artefact is a root-executed timer on a Linux server fleet whose target script sits in a directory a deployment account can write. Two goals ride it. ## Goal one: Privilege Escalation What the arrangement buys is a **transition** — a write performed as a low-privileged principal becomes execution in a root context. That is the whole product. It does not matter that it happens on a schedule; the schedule is just the trigger. What removes it: make the executed path unwritable from the lower context. Concretely that means root ownership and root-only write on the script *and* on every directory in its path — a writable parent directory is as good as a writable file, since the file can be replaced. The unit directory itself is root-only for the same reason. What the operator substitutes: **nothing**, unless another root-executed path is reachable from the same account. The transition is not a behaviour they can perform differently; it is a property of the estate. Take it away and the capability is gone, not relocated. That is the signature of a control worth buying. ## Goal two: Persistence What the arrangement buys is **continuity** — execution comes back after a reboot or a lost session without re-authenticating. The timer is one carrier among many. On the same fleet the goal is equally served by a cron entry, another unit, a user-level unit, a shell profile, or a wrapper on something already scheduled. What removes it: not a ban on timers. The goal is removed only at the level of the whole surface — scheduled work is reconciled from a source of truth, so any unit that was not declared there does not survive the next reconciliation, whatever mechanism placed it. That is a bigger, slower and more expensive change, because it requires that every legitimate job have a declared owner. What the operator substitutes if you only block timers: **the next carrier**, at a cost of minutes. You will have spent effort and removed nothing. ## The sequencing call Privilege Escalation first, for three reasons that hold generally and not just here. 1. **No substitute.** A goal with no alternative carrier is fully removed by one narrow change. A goal with many carriers is not removed at all by any narrow change. 2. **It is upstream of the other's value.** Root-context execution is what makes the persistence worth having; continuity as an ordinary deploy account is a far cheaper problem. 3. **It is affordable now.** File ownership and directory permissions on one path is a change with an owner and a same-week timeline. Reconciling all scheduled work across a fleet is a programme. That sequencing does not mean the Persistence goal is dismissed. It means it is booked as the larger piece of work it actually is, rather than papered over with a control that reads well and moves nothing. ## The trap: remediating the artefact The tempting response is 'remove the timer and alert on new ones'. Removing the timer removes today's instance of both goals and neither goal itself. It also removes the cheapest thing the operator had, which is not the same as removing the cheapest thing they *can get*. If the deploy account still writes into a root-executed path, they have the same transition available through whatever is scheduled next. ## What to say when asked State the two goals separately, price the substitution for each, then commit: fix the write-to-root-execution path now because it has no substitute, and open the scheduled-work reconciliation as separate work because that is what the continuity goal actually costs. An answer that names one remedy without naming which goal it removes has skipped the only step that makes the remedy defensible.
- Why is a writable parent directory as serious as a writable script?Because the file can be replaced rather than edited. Write access to a directory allows creating, renaming and unlinking entries within it, so the root-executed path can be swapped for a different file entirely. Any permission fix has to cover every directory along the path, not just the leaf, or the transition survives untouched.
- If you can only fund one of the two changes this quarter, which and why?The permissions fix on the root-executed path. It removes a goal outright, the operator has no substitute for it, it has a single named owner and it lands in days. The scheduled-work reconciliation removes a goal with many carriers and requires every legitimate job across the fleet to acquire a declared owner first, which makes it a programme, not a task.
- Suppose the deploy account is itself root. Does the analysis change?Yes — the Privilege Escalation goal disappears, because a principal that already holds root gains nothing by reaching root. Only continuity is left, and the whole answer moves to the harder ground: reconciling scheduled work. It also reframes the real finding as the deploy account holding root at all, which is a separate goal removal.
saying these in an interview costs you the question
- Removes the timer and calls the goal removed
- Names a remedy without naming which goal it removes
- Blocks one scheduling mechanism against a many-carrier goal
- Fixes the script permissions but leaves the directory writable
- Assumes a single artefact can only serve one goal