Process identity and containment sessions
Before BitShout can decide anything, it has to answer one question without guessing — who exactly is asking. Everything downstream consumes that answer.
Every other decision in BitShout consumes this one. A filesystem verdict, a network verdict, an execution verdict and a capability verdict all begin by resolving the requesting process to a registered protected subject and an active containment session. If that resolution fails, the request does not fall through to a default allow — it fails closed.
What counts as identity
A process name is a string the process chose. A PID is a number the kernel will reuse. Neither is identity, and BitShout treats neither as authoritative.
What it does treat as identity:
- Code-signing identity and signing status of the executable
- Team ID and bundle identifier
- Executable identity — the canonical executable and its hash where available
- Process audit token, which the kernel issues and a process cannot forge
- Parent-child lineage, resolved as a chain rather than a single hop
A registered protected subject is a fingerprint over that evidence, not a path. Moving a binary does not change what it is; replacing the binary at a path does.
Containment sessions
When a protected subject starts, BitShout opens a containment session and binds the process instance to it. The session is the unit that grants attach to, that evidence correlates on, and that descendants inherit.
Sessions carry:
- session identity and lifecycle state
- the registered subject fingerprint that opened them
- membership for every descendant process instance
- the security generation they were created under
That last one matters more than it sounds. If the security generation advances — because protection locked and was recovered, or because policy state was rebuilt — authority created under the old generation stops matching. Stale authority does not survive a reset by accident.
Resolution outcomes
Resolving a PID to a containment answer has four possible results, and only one of them means BitShout policy does not apply:
| Result | Meaning | Effect on contained-security decisions |
|---|---|---|
contained |
The process is in an active session | BitShout policy applies |
notContained |
Ordinary host process | notDetermined — BitShout does not govern it |
unresolved |
Identity could not be established | Deny |
staleIdentity |
Evidence no longer matches | Deny |
unresolved and staleIdentity are the interesting rows. Both are states of not
knowing, and both deny rather than converting uncertainty into trust. This is Law 8
implemented at the very first step, which is the only place it can be implemented
cheaply — every later stage inherits it.
Application replacement
Applications update. An update is a new executable with a new hash and, potentially, a different signing identity. BitShout revalidates the subject fingerprint rather than assuming the thing at that bundle path is still the thing you registered.
The result is that an updated application is re-recognised on its merits, and a replaced application is not silently handed the grants that belonged to its predecessor.
What Phase 1 does not do
It does not enforce anything. It establishes who is asking, deterministically, so the filesystem, network, execution and capability domains have a subject to reason about. Identity without a policy is an observation; the filesystem model is where the first policy decision gets made.