2.2 Bootstrap Identity
The steady-state identity flow is: peinit asks authd for a token, authd mints it, peinit installs it on the child. That flow cannot start the system, because authd depends on lpsd, lpsd depends on registryd, and registryd has to be running before any of them. The bootstrap model breaks the circle.
2.2.1 Platform services run as SYSTEM #
A service whose definition says Identity=SYSTEM gets a token peinit
mints from its own, with kacs_create_token (§4.2). No authd
interaction is involved — which is the point, since authd does not exist
when the first of these services starts.
Four services use it:
| Service | Why |
|---|---|
| registryd | Starts before authd exists at all. |
| lpsd | Must be running before authd can resolve a local identity. |
| authd | Needs SeTcbPrivilege and SeCreateTokenPrivilege; it is the minter for everything else. |
| eventd | Starts early, before authd is necessarily available. |
Nothing restricts which services may declare Identity=SYSTEM. There is
no allowlist, because an allowlist would be enforcing a boundary that is
already enforced somewhere better: the Security Descriptor on
Machine\System\Services\. Anyone who can create a service definition
is by definition trusted to choose its identity, and adding a second
list to maintain would only create a way for the two to disagree.
Every SYSTEM token peinit mints carries the service's per-service SID in
its group list, computed by peinit itself from the service name (§4.4).
That is what keeps platform services distinguishable to an access check
despite all of them running as S-1-5-18.
2.2.2 After authd #
Once authd and lpsd are running, every subsequent service gets its token
through the ordinary authd flow (§4.3). A definition with no Identity
field defaults to LocalService — a well-known principal with a minimal
privilege set — and authd adds the per-service SID to the token it
mints.