# Peios Security Fundamentals > The Peios Security Model. All of Peios Security Fundamentals as one markdown file: [/peios/security-fundamentals/print.md](/peios/security-fundamentals/print.md) ## Identity - [Identity in Peios](/peios/security-fundamentals/identity/overview.md): How Peios identifies who is acting — principals named by SIDs, carried by tokens, anchored in logon sessions, and checked at every access decision. - [SIDs](/peios/security-fundamentals/identity/sids.md): A SID (Security Identifier) is the unique name for a principal — the string form you see in logs, the binary form on the wire, and the comparison rule. - [Well-known principals](/peios/security-fundamentals/identity/well-known-principals.md): The catalog of principals whose SIDs are fixed by the system — what each well-known SID means, how it behaves in an access check, and which ones to use. - [Claims on a token](/peios/security-fundamentals/identity/claims.md): Claims are typed key-value attributes on a token — user and device attributes from the directory that conditional ACEs evaluate during access checks. ## Tokens - [Tokens](/peios/security-fundamentals/tokens/overview.md): A token is the kernel object that carries an identity into every system call — what it contains, where it comes from, and how it lives and dies. - [Token types and fields](/peios/security-fundamentals/tokens/token-types.md): The axes a token is classified along — primary or impersonation, impersonation level, restricted, elevation type — and the token's fields grouped by purpose. - [Token lifecycle](/peios/security-fundamentals/tokens/lifecycle.md): A token's life from minting by authd or peinit to destruction at the last reference — fork, exec, impersonation, adjustment, and the default DACL. - [Restricted and write-restricted tokens](/peios/security-fundamentals/tokens/restricted-tokens.md): A restricted token carries a secondary SID list; AccessCheck runs twice and intersects the results. Write-restricted applies the same idea to write rights only. - [Elevation and linked tokens](/peios/security-fundamentals/tokens/elevation.md): Some principals carry two linked tokens — a Limited default and a Full elevated half — paired on the logon session and switched on request. - [The token command](/peios/security-fundamentals/tokens/token-command.md): The token command inspects and manipulates tokens — reading a token's contents, adjusting it, duplicating and restricting it, and driving impersonation. ## Logon Sessions - [Logon sessions](/peios/security-fundamentals/logon-sessions/overview.md): A logon session is the kernel object recording one authentication event — every token belongs to exactly one, tied together by the session's logon SID. - [Logon types](/peios/security-fundamentals/logon-sessions/logon-types.md): Every logon session is tagged with a logon type — Interactive, Network, Batch, Service, NetworkCleartext, or NewCredentials — and what each type means. - [Session lifecycle](/peios/security-fundamentals/logon-sessions/lifecycle.md): A logon session is created by authd at successful authentication and destroyed when its last token reference drops — there is no kernel revocation primitive. - [The logonse command](/peios/security-fundamentals/logon-sessions/logonse-command.md): The logonse command lists logon sessions and their processes, creates and destroys them, and sets a process's mitigation flags. ## Signing In - [Signing in](/peios/security-fundamentals/signing-in/overview.md): How a sign-in works on Peios — the conversation with the authority on /run/logon.sock, the roles involved, and why authentication and derivation are separate. - [The login command](/peios/security-fundamentals/signing-in/the-login-command.md): login is the terminal client for PGSS Logon — it collects an identifier and whatever credentials the authority asks for, and starts your shell. ## Managing Local Principals - [Managing local principals](/peios/security-fundamentals/managing-local-principals/overview.md): Where the accounts on a Peios machine live — the authority that mints tokens, the sources that hold identity, and lpsd, the one that owns the local store. - [The local store](/peios/security-fundamentals/managing-local-principals/the-local-store.md): What lpsd keeps on disk — the machine's domain SID, its principals, and the argon2id verifiers that stand in for their passwords — and why it is one file. - [Creating accounts](/peios/security-fundamentals/managing-local-principals/creating-accounts.md): How the first account on a machine comes to exist, how to create the ones after it, and what happens on an image that ships a development account. - [The lps command](/peios/security-fundamentals/managing-local-principals/lps-command.md): The lps command administers the local principal store — principals, passwords, groups and memberships, profiles, and claims. - [The administrative socket](/peios/security-fundamentals/managing-local-principals/the-admin-socket.md): The socket lps talks to lpsd over — where it is, who may use it, and what decides that. Useful if you are writing tooling against it or diagnosing a refusal. - [Resolving names](/peios/security-fundamentals/managing-local-principals/resolving-names.md): How a name, a SID or a POSIX identifier becomes a principal — why only the authority can answer, the search order, and why "unavailable" is not "not found". ## Impersonation - [Impersonation](/peios/security-fundamentals/impersonation/overview.md): How a thread temporarily acts as another principal — the two-token model, the canonical server flow, and just-in-time impersonation for modern runtimes. - [Impersonation levels](/peios/security-fundamentals/impersonation/impersonation-levels.md): The four impersonation levels — Anonymous, Identification, Impersonation, Delegation — what each permits, and the pitfalls each one produces. - [The two-gate model](/peios/security-fundamentals/impersonation/the-two-gates.md): The two gates that decide a server's effective impersonation level — the identity gate and the integrity ceiling — and the silent downgrade they produce. - [Peer tokens and capture](/peios/security-fundamentals/impersonation/peer-tokens.md): How the kernel captures a client's identity onto a socket at connect, the two syscalls that use it, which transports carry peer tokens, and identity cascading. ## Security Descriptors - [Security descriptors](/peios/security-fundamentals/security-descriptors/overview.md): Every protected object carries one security descriptor — the owner, primary group, DACL, and SACL that define who may do what to it and what is audited. - [ACLs, ACEs, and access masks](/peios/security-fundamentals/security-descriptors/acls-and-aces.md): The shared structure of DACLs and SACLs — ACL and ACE layout, the catalog of ACE types, the inheritance and audit flags, and the 32-bit access mask. - [DACL evaluation](/peios/security-fundamentals/security-descriptors/dacl-evaluation.md): How a DACL decides — the first-writer-wins walk, canonical ACE order, the NULL-vs-empty DACL distinction, and what MAXIMUM_ALLOWED changes. - [Ownership and implicit rights](/peios/security-fundamentals/security-descriptors/ownership.md): The owner's implicit READ_CONTROL and WRITE_DAC — the you-cannot-lock-yourself-out guarantee — how OWNER RIGHTS suppresses them, and changing ownership. - [Inheritance](/peios/security-fundamentals/security-descriptors/inheritance.md): A child's SD is computed once, at creation, from the parent's inheritable ACEs and the creator's defaults — the parent is never walked at access-check time. - [Conditional ACEs](/peios/security-fundamentals/security-descriptors/conditional-aces.md): An ACE gated by an expression over token claims, resource attributes, and local context — the model, the expression language, and the three-valued logic. - [Resource attributes](/peios/security-fundamentals/security-descriptors/resource-attributes.md): A typed key-value attribute attached to an object through its SACL — referenced by conditional ACEs as @Resource., never granting anything by itself. - [The SACL](/peios/security-fundamentals/security-descriptors/the-sacl.md): The system half of a security descriptor — audit and alarm ACEs, the integrity label, the PIP trust label, scoped policy references, and resource attributes. - [The sd command](/peios/security-fundamentals/security-descriptors/sd-command.md): The sd command reads and changes a file's security descriptor — owner, access rules, audit rules, integrity label, and inheritance. ## Privileges - [Privileges](/peios/security-fundamentals/privileges/overview.md): A privilege is a system-wide right carried on a token — gating a specific operation regardless of who you are, granted by this machine's policy at logon. - [Privilege lifecycle](/peios/security-fundamentals/privileges/lifecycle.md): Each privilege on a token is absent, present-disabled, present-enabled, or used — the transitions between states, AdjustPrivileges, and why removal is one-way. - [Intent-gated privileges](/peios/security-fundamentals/privileges/intent-gated.md): SeBackup and SeRestore participate in a check only when the caller passes BACKUP_INTENT or RESTORE_INTENT — why intent gating exists and how the flags work. - [Privilege categories](/peios/security-fundamentals/privileges/categories.md): The four functional categories of privilege — kernel-standalone, AccessCheck-influencing, application-level, and reserved — and what each one does. - [Assigning privileges](/peios/security-fundamentals/privileges/assigning-privileges.md): The policy records under Machine\Generic\Authn\Policy that authd reads at every logon — which privileges a principal gets, and at what integrity level. ## Access Decisions - [Access decisions](/peios/security-fundamentals/access-decisions/overview.md): AccessCheck takes a token, an object's security descriptor, and a desired access mask, and runs a multi-stage pipeline to produce a granted mask. - [Mandatory integrity control](/peios/security-fundamentals/access-decisions/mandatory-integrity-control.md): MIC gates access by integrity level — the object's label in its SACL against the token's own level, compared before the DACL walk ever runs. - [Privileges in the pipeline](/peios/security-fundamentals/access-decisions/privileges-in-the-pipeline.md): Where each AccessCheck-influencing privilege fires in the pipeline, which bits it grants, what it does not bypass, and how its grant is recorded for audit. - [Narrowing layers](/peios/security-fundamentals/access-decisions/narrowing-layers.md): The three layers that can only remove access — the restricted-token pass, confinement, and central access policies — in pipeline order, and what bypasses each. - [Debugging a denial](/peios/security-fundamentals/access-decisions/debugging-a-denial.md): An access was denied and you need to know why — the systematic walk through the pipeline, what to inspect, in what order, and what each finding means. ## Central Access Policies - [Central access policies](/peios/security-fundamentals/central-access-policies/overview.md): A central access policy is defined once and applied to many objects — referenced by SID from the SACL, evaluated at access-check time, and only ever narrowing. - [Policies and rules](/peios/security-fundamentals/central-access-policies/policies-and-rules.md): A policy is a versioned bundle of rules — each with an optional applies-to expression, an effective DACL and SACL, and staged versions for testing. - [Evaluation](/peios/security-fundamentals/central-access-policies/evaluation.md): CAAP runs at step 12 — each referenced policy looked up, each applicable rule's effective DACL intersected with the running grant, with no recursion. - [Staged policies](/peios/security-fundamentals/central-access-policies/staged-policies.md): A rule's staged DACL and SACL are evaluated in parallel without affecting access — the staging mismatch flag shows where a proposed change would differ. - [Distribution and recovery](/peios/security-fundamentals/central-access-policies/distribution-and-recovery.md): authd pushes policies into the kernel's cache via kacs_set_caap — empty at boot, a recovery policy for missing references, replication as authd's job. ## File access - [File access](/peios/security-fundamentals/file-access/overview.md): FACS applies KACS access control to files. AccessCheck runs once at open; the granted mask is cached on the fd and gates every later operation. - [The handle model](/peios/security-fundamentals/file-access/the-handle-model.md): Every FACS-managed fd carries a granted access mask, stamped at open and immutable. What the cache contains, which operations consult it, and fd transfer. - [Opening files](/peios/security-fundamentals/file-access/opening-files.md): kacs_open with an explicit desired mask versus legacy openat with POSIX flags — strict-mode grants, create dispositions, MAXIMUM_ALLOWED, and SD-at-creation. - [Managing file security](/peios/security-fundamentals/file-access/managing-file-security.md): Reading and writing file SDs with kacs_get_sd and kacs_set_sd — the security_information bitmask, per-component access rules, and the LABEL flag. - [Special cases](/peios/security-fundamentals/file-access/special-cases.md): The edges of FACS — O_PATH, the exec dual gate, append-only handles, the inert sticky bit, replaced POSIX ACLs, NFS dual authority, and whiteouts. ## Confinement - [Confinement](/peios/security-fundamentals/confinement/overview.md): Confinement is the Peios sandbox model — policy applied to an application from outside that narrows what its token can reach, past even what privileges bypass. - [Capabilities and modes](/peios/security-fundamentals/confinement/capabilities-and-modes.md): A confined application's reach as capability SIDs — the well-known set, SHA-256-derived custom capabilities, and the normal and strict confinement modes. - [The confinement pass](/peios/security-fundamentals/confinement/the-confinement-pass.md): Confinement fires at step 11 as an absolute intersection — the DACL re-walked against the confinement identity, with nothing restored afterwards. - [Positive confinement](/peios/security-fundamentals/confinement/positive-confinement.md): A capability SID placed in a token's normal groups grants access through the ordinary DACL walk — the canonical pattern for service access at scale. ## Process Integrity Protection - [Process integrity protection](/peios/security-fundamentals/process-integrity-protection/overview.md): PIP gates operations between processes by the trust of their binaries — a two-dimensional label set by the kernel at exec from the binary's signature. - [The process security descriptor](/peios/security-fundamentals/process-integrity-protection/the-process-security-descriptor.md): Every process carries its own security descriptor on the PSB, gating who may signal, debug, inspect, or modify the running process. - [The two-check rule](/peios/security-fundamentals/process-integrity-protection/the-two-check-rule.md): Every cross-process operation runs an SD check and a PIP dominance check — both must pass, and no privilege bypasses the PIP half. - [PIP in practice](/peios/security-fundamentals/process-integrity-protection/pip-in-practice.md): PIP's practical edges — the impersonation asymmetry, peinit as lifecycle manager, MIC versus PIP, the threat-model ceiling, and the v0.20 limits. ## Binary Signing - [Binary signing](/peios/security-fundamentals/binary-signing/overview.md): A signed binary carries an ML-DSA-65 signature the kernel verifies at exec to set its PIP level — signing only adds trust, never blocks execution. - [Signature format](/peios/security-fundamentals/binary-signing/signature-format.md): The 3310-byte signature blob — a version byte plus an ML-DSA-65 signature over a SHA-256 hash — and where it lives for ELF and non-ELF files. - [Verification and pinning](/peios/security-fundamentals/binary-signing/verification-and-pinning.md): How the kernel verifies at exec — the flow, the stable-snapshot rule, scripts and interpreters, symlinks, and inode pinning after verification. - [Keys and image build](/peios/security-fundamentals/binary-signing/keys-and-image-build.md): The public-key catalog compiled into the kernel, the TCB private key held only by image builders, and the peiso signing flow. ## Process Mitigations - [Process mitigations](/peios/security-fundamentals/process-mitigations/overview.md): A mitigation is a one-way, kernel-enforced hardening flag on the PSB — restricting what a process may do with its own memory, control flow, and children. - [Catalog](/peios/security-fundamentals/process-mitigations/catalog.md): The eight active mitigations — LSV, WXP, TLP, CFIF, CFIB, PIE, SML, NO_CHILD — what each one gates, what it blocks, and when to enable it. - [Applying and lifecycle](/peios/security-fundamentals/process-mitigations/applying-and-lifecycle.md): Mitigations are set via kacs_set_psb — free on your own process, privileged on another — and persist one-way through fork and exec. ## Auditing - [Auditing](/peios/security-fundamentals/auditing/overview.md): Auditing records what happened, separate from what was allowed. Audit ACEs, token audit policy, and delivery through KMES to userspace consumers. - [Audit ACEs](/peios/security-fundamentals/auditing/audit-aces.md): SYSTEM_AUDIT ACEs fire once per access check; SYSTEM_ALARM ACEs audit every operation on the handle. Polarity, conditional variants, and inheritance. - [Policy-forced auditing](/peios/security-fundamentals/auditing/policy-forced-auditing.md): Privilege-use audit and the token's audit_policy bitmask fire events without any SACL ACE. When each fires and how they compose with SACL-driven audit. - [Events and transport](/peios/security-fundamentals/auditing/events-and-transport.md): The audit event schemas and the KMES transport that carries them — access-audit, continuous-audit, privilege-use, and logon-session-destroyed. ## Inspecting security state - [Inspecting security state](/peios/security-fundamentals/inspecting/overview.md): Read-only surfaces for live KACS state — /proc token files, the securityfs listings, and the KACS_IOC_QUERY ioctl — plus the access rules for reading them. - [Inspecting tokens](/peios/security-fundamentals/inspecting/tokens.md): Reading a token with KACS_IOC_QUERY on a token fd — obtaining fds, the query mechanics, the two-call pattern for variable-length data, and the class catalog. - [Inspecting sessions](/peios/security-fundamentals/inspecting/sessions.md): Active logon sessions are listed at /sys/kernel/security/kacs/sessions. The listing format, the token-to-session lookup pattern, and lifecycle tracking. - [Inspecting processes](/peios/security-fundamentals/inspecting/processes.md): Inspecting a process's PSB (PIP, mitigations) and process SD. Your own state is free; another process needs PROCESS_QUERY_INFORMATION plus PIP dominance. - [The event stream](/peios/security-fundamentals/inspecting/the-event-stream.md): revstrm is a diagnostic probe that attaches directly to the KMES ring buffers and prints every audit event it drains. Options, output format, and caveats. ## Boot and trust establishment - [Boot and trust establishment](/peios/security-fundamentals/boot-and-trust-establishment/overview.md): How a freshly-started kernel becomes a running system with real identities — bootstrap tokens, the initramfs, peinit at PID 1, and the authd handoff. - [Bootstrap tokens](/peios/security-fundamentals/boot-and-trust-establishment/bootstrap-tokens.md): Before userspace exists the kernel constructs two tokens — authority-maximal SYSTEM and identity-minimal Anonymous — that bootstrap the identity model. - [The initramfs stage](/peios/security-fundamentals/boot-and-trust-establishment/initramfs-stage.md): Between kernel init and peinit, prelude — the initramfs PID 1 — prepares the environment, runs the boot hooks that mount the real root, and hands off. - [Boot hooks](/peios/security-fundamentals/boot-and-trust-establishment/boot-hooks.md): Boot hooks do the deployment-specific work of early boot. Where they live, the metadata block, the four ordering keys, and the exit-code protocol. - [peinit at PID 1](/peios/security-fundamentals/boot-and-trust-establishment/peinit-pid-1.md): Why peinit is PID 1 — TCB-signed, holding the SYSTEM token — and the fork-install-exec pattern that launches every service with the right identity. - [authd handoff](/peios/security-fundamentals/boot-and-trust-establishment/authd-handoff.md): When authd comes online the system moves from SYSTEM-everywhere to real identities — token minting, session management, and CAAP distribution. - [Kernel invariants](/peios/security-fundamentals/boot-and-trust-establishment/kernel-invariants.md): The kernel-level invariants the boot chain depends on — the LSM stack rule, forced module signing, strict /dev/mem — and what fails without them. - [mkirf](/peios/security-fundamentals/boot-and-trust-establishment/mkirf.md): Compile the /boot/initramfs/ source tree into a deterministic cpio initramfs image, resolving hook order and validating the layout. Has a watch mode. - [mkuki](/peios/security-fundamentals/boot-and-trust-establishment/mkuki.md): Build a UEFI unified kernel image — kernel, initramfs, and command line appended as PE sections onto an EFI stub. Has a watch mode.