← ClaudeAtlas

security-race-and-toctoulisted

Design controlled concurrency tests for authorization reuse, check/use identity changes, and non-atomic state transitions. Use for one-use grants, filesystem snapshots, competing reservations, or cancellation races. Not a broad penetration test or kernel exploitation workflow.
dills122/ai-central · ★ 0 · Data & Documents · score 69
Install: claude install-skill dills122/ai-central
# Race And TOCTOU Testing Find a schedule that violates a documented invariant, then preserve it as a bounded regression. TOCTOU means that an observation no longer justifies the later operation because relevant state or identity changed between them. ## Model The Competing Operations Name the checked object, the action that uses it, and the actor able to change it. Record the target revision and actual contract for revocation, expiry and one-use consumption. Continued work after revocation is not automatically a bug: determine whether the contract authorizes a snapshot or requires continuing authorization. Locate the atomic decision point and what protects it: transaction, lock, compare-and-swap, immutable snapshot or OS handle. Determine whether every competing path participates in that mechanism. A thread-race detector can miss a logical race that spans individually synchronized operations or separate processes. ## Construct A Controlled Schedule 1. Use local synthetic grants, isolated stores and fixture files. Identify owned workers, total attempts, per-wait deadlines and cleanup before execution. 2. Place a test barrier or fault hook after the relevant check and before use; perform the competing mutation, then release the operation. The hook must not create a behavior impossible in the real code or bypass the control under test. 3. Assert complete effects, not only return values. For a one-use grant, count successful authority-bearing effects and inspec