4.4 Well-Known SIDs

The following SIDs have fixed values and well-defined meanings. An implementation MUST recognise these SIDs and apply their defined semantics wherever they are referenced. The access-check behaviour attached to them is described in the Peios Kernel TRM §3.8.

4.4.1 Universal authorities #

SIDNameDescription
S-1-0-0NobodyThe null SID. No principal.
S-1-1-0EveryoneMatches all principals, including anonymous.
S-1-2-0LocalPrincipals that log on locally (physically).
S-1-2-1Console LogonPrincipals that log on via the physical console.

4.4.2 Creator authorities #

SIDNameDescription
S-1-3-0Creator OwnerPlaceholder in inheritable ACEs. Replaced with the creating principal's SID during inheritance.
S-1-3-1Creator GroupPlaceholder in inheritable ACEs. Replaced with the creating principal's primary group SID during inheritance.
S-1-3-4Owner RightsWhen present in a DACL, overrides the owner's implicit READ_CONTROL and WRITE_DAC grants. AccessCheck treats this SID as matching the object's owner.

4.4.3 NT Authority (S-1-5) #

SIDNameDescription
S-1-5-2NetworkPrincipals that authenticated over the network.
S-1-5-4InteractivePrincipals that logged on interactively.
S-1-5-6ServicePrincipals that authenticated as a service.
S-1-5-7AnonymousThe anonymous identity. Carried by tokens at Anonymous impersonation level.
S-1-5-10Principal SelfPlaceholder in ACEs on directory objects. Matches the caller when the caller's identity corresponds to the object's associated principal. Resolved via the self_sid parameter to AccessCheck.
S-1-5-11Authenticated UsersAll principals that have been authenticated (excludes Anonymous).
S-1-5-18Local System (SYSTEM)The operating system's own identity. Highest privilege level.
S-1-5-19Local ServiceA built-in service account with reduced privileges.
S-1-5-20Network ServiceA built-in service account that can authenticate to remote services.

4.4.4 Logon SIDs #

SIDNameDescription
S-1-5-5-X-YLogon SIDA per-authentication-event SID generated at LogonSession creation. X and Y are unique values. Injected into the token's groups with SE_GROUP_LOGON_ID.

4.4.5 BUILTIN domain (S-1-5-32) #

SIDNameDescription
S-1-5-32-544BUILTIN\AdministratorsThe built-in administrators group.
S-1-5-32-545BUILTIN\UsersThe built-in users group.
S-1-5-32-546BUILTIN\GuestsThe built-in guests group.
S-1-5-32-551BUILTIN\Backup OperatorsMembers can bypass file security for backup and restore.

4.4.6 Domain SIDs (S-1-5-21) #

Domain-specific SIDs follow the pattern S-1-5-21-{DA1}-{DA2}-{DA3}-{RID}, where the three domain authority sub-authorities identify the domain and the RID identifies the principal within that domain.

RIDNameDescription
500Domain AdministratorThe built-in administrator account.
501Domain GuestThe built-in guest account.
512Domain AdminsThe domain administrators group.
513Domain UsersThe domain users group.
514Domain GuestsThe domain guests group.
515Domain ComputersComputer accounts in the domain.

4.4.7 Mandatory integrity labels (S-1-16) #

SIDNameNumeric levelDescription
S-1-16-0Untrusted0Lowest trust. Sandboxed or experimental code.
S-1-16-4096Low4096Reduced trust. Services handling untrusted input.
S-1-16-8192Medium8192Standard trust. Default for interactive logons and most services.
S-1-16-12288High12288Elevated administrative logons.
S-1-16-16384System16384The kernel, peinit, and TCB services.

The five levels above are the standard, well-known integrity levels; in practice they behave like an enum. Technically the level is the SID's single sub-authority as an unsigned integer: any S-1-16-<n> with exactly one sub-authority is a valid level, and MIC compares levels numerically. Non-standard values occur in Windows-interop SDs — e.g. S-1-16-8448 (medium-plus) or S-1-16-20480 (protected). A mandatory-label SID with a different identifier authority or more than one sub-authority is malformed and rejected. The standard order is System > High > Medium > Low > Untrusted.

4.4.8 Process trust labels (S-1-19) #

SIDNameDescription
S-1-19-0-0None / No trustDefault for unsigned processes.
S-1-19-512-1024Protected, AuthenticodeThird-party signed binaries.
S-1-19-512-1536Protected, AntiMalwareSecurity tooling.
S-1-19-512-2048Protected, AppPeios-distributed applications.
S-1-19-512-4096Protected, PeiosCore Peios components.
S-1-19-512-8192Protected, PeiosTcbPeios Trusted Computing Base.
S-1-19-1024-8192Isolated, PeiosTcbMaximum isolation and trust.

Trust labels encode two dimensions in the SID: the first sub-authority is the PIP type axis and the second is the trust axis (higher = more trusted). Dominance requires both dimensions to be greater than or equal.

KACS currently standardises these PIP type values:

  • 0 = None
  • 512 = Protected
  • 1024 = Isolated

These values are standardised labels, not a closed enum for AccessCheck. Other numeric type values remain valid and are compared numerically by the same dominance rule.

4.4.9 Confinement SIDs (S-1-15) #

SIDNameDescription
S-1-15-2-hashConfinement SIDIdentifies a confined application. The sub-authorities are derived from the application identity.
S-1-15-2-1ALL_APPLICATION_PACKAGESMatches all confined applications in normal confinement mode.
S-1-15-2-2ALL_RESTRICTED_APPLICATION_PACKAGESMatches confined applications in both normal and strict confinement modes. Strict confinement is the mode where ALL_APPLICATION_PACKAGES is omitted from the capabilities.

4.4.10 Capability SIDs (S-1-15-3) #

SIDNameDescription
S-1-15-3-1internetClientOutbound internet access.
S-1-15-3-2internetClientServerInbound and outbound internet access.
S-1-15-3-3privateNetworkClientServerLAN/private network access.
S-1-15-3-8enterpriseAuthenticationDomain credential access.
S-1-15-3-9sharedUserCertificatesCertificate store access.
S-1-15-3-10removableStorageRemovable media access.

Capability SIDs 4–7 (picturesLibrary, videosLibrary, musicLibrary, documentsLibrary) are reserved. Their SID values MUST NOT be redefined.

Derived capabilities use 8 sub-authorities computed from the SHA-256 hash of the capability name: S-1-15-3-{h0}-{h1}-{h2}-{h3}-{h4}-{h5}-{h6}-{h7}. The same name always produces the same SID.

4.4.11 Service SIDs #

Service SIDs follow the pattern SERVICE\{service_name} (e.g., SERVICE\jellyfin, SERVICE\loregd) and are added as a group in the service's token. The token's primary user SID is the account the service runs as (typically SYSTEM, LocalService, or NetworkService); the service SID enables per-service access control — a file's DACL can grant access to SERVICE\jellyfin specifically, rather than to the broad account the service runs under.

The SID value is derived from the service name using a SHA-1 hash: the UTF-16LE encoding of the uppercased service name is hashed, and the 20-byte digest is split into five little-endian 32-bit sub-authorities: S-1-5-80-{h0}-{h1}-{h2}-{h3}-{h4}. The same service name always produces the same SID. This matches the Windows service SID derivation (MS-DTYP compatible).

Edit this page