2.9 Establishing What a Source Is
The authority MUST establish a connecting source's identity for itself, from the kernel, and MUST NOT take it from anything the source sends.
2.9.1 A source proves nothing #
The mechanism worth recommending is that a source proves nothing at all, because the init system already did.
Where the init system places a service SID in each service's token — a SID derived from the service's name, which only the init system can mint — the authority can:
- take its list of permitted source names from its own configuration;
- derive the service SID each of those names implies;
- read the connecting peer's token and ask which of those SIDs it carries.
The resulting identity is assembled entirely from the authority's configuration and the kernel. Nothing is contributed by the process on the other end. There is no shared secret, nothing to provision, nothing to rotate, and nothing to steal — the derivation is a pure function of a name that only the init system can act on.
2.9.2 What is deliberately not checked #
That the peer is SYSTEM. The service SID subsumes it: the user SID could never distinguish one platform service from another, since they all run as the same principal. Requiring SYSTEM as well would needlessly forbid a future source running under a lesser account, which is a direction worth keeping open.
2.9.3 The allowlist #
An authority MUST NOT accept a source it has not been configured to accept.
An empty configuration MUST mean no source may register, not any source may. An allowlist that fails open is not an allowlist. The visible cost is that a system configured with no sources cannot authenticate anyone, which is the correct way for that mistake to present — loudly, at the first logon attempt, rather than silently at the first compromise.