These docs are under active development and cover the v0.20 Kobicha security model.

Contents

1Introduction

2Sids

3Security descriptors

4Tokens

5Psb

6Signing

7Privileges

8Pip

9Impersonation

10Access check

11Facs

12Linux credential model

13Appendix a

14Appendix b

§1.1 1 Introduction

Scope

This specification defines the Kernel Access Control Subsystem (KACS) for the Peios operating system. KACS is a Linux Security Module (LSM) within the Peios Kernel Module (PKM) that provides identity-based access control in the Linux kernel.

KACS is the sole identity-based authorization mechanism for managed objects in Peios. All identity-based authorization decisions -- file opens, registry reads, IPC connections, signal delivery, token operations -- pass through a single evaluation function, AccessCheck.

This specification covers:

  • Security Identifiers (SIDs) -- the principal identification format
  • Tokens -- per-thread identity objects carrying SIDs, groups, privileges, and integrity levels
  • The Process Security Block (PSB) -- per-process security properties independent of identity
  • Security Descriptors (SDs) -- per-object security policy structures containing access control lists
  • Privileges -- system-wide rights carried on tokens
  • AccessCheck -- the complete authorization evaluation algorithm
  • Impersonation -- per-thread identity substitution with level controls
  • Process Integrity Protection (PIP) -- process-level isolation based on binary trust
  • File Enforcement (FACS) -- the file access control implementation mapping SDs to VFS operations
  • The Linux credential model under KACS -- credential projection, DAC neutralization, and UID semantics

This specification does not cover:

  • Authentication (authd)
  • The principal store or directory services
  • The registry subsystem (loregd)
  • Service management (peinit)
  • The Job Forwarding Subsystem (JFS)
  • The event and audit subsystem (KMES -- specified separately)
  • Network-level delegation and Kerberos integration
  • Container integration
§1.2 1 Introduction

Terminology

The following terms are used throughout this specification with the precise meanings defined here.

KACS (Kernel Access Control Subsystem): The access control subsystem within PKM. Implements per-thread tokens, Security Descriptors, AccessCheck, privileges, and impersonation. KACS is the sole identity-based authorization engine for managed objects.

PKM (Peios Kernel Module): The single compiled-in kernel module containing all Peios kernel extensions. KACS is one of the subsystems within PKM.

Token: A per-thread identity object maintained by KACS in the kernel's credential structure. Contains: a user SID, group SIDs, a privilege bitmask, an integrity level, an impersonation level, and metadata. Tokens are immutable in their identity fields (SIDs, type, integrity level) and atomically adjustable in their policy fields (privileges enabled, groups enabled, default owner/group/DACL). Every thread has a token; there are no NULL tokens.

Primary token: The token that defines a process's baseline identity. Inherited by child processes on fork. Stored via task->real_cred.

Impersonation token: A temporary, per-thread token that overrides the primary token for access control decisions. Stored via task->cred. Only affects the thread that set it.

SID (Security Identifier): A unique, hierarchical principal identifier. Format: S-1-{authority}-{sub1}-{sub2}-.... SIDs identify users, groups, services, machines, and well-known principals. SIDs are binary-compatible with Windows SIDs.

Security Descriptor (SD): A binary structure defining the security policy for a protected object. Contains: an owner SID, a primary group SID, a DACL, and optionally a SACL. SDs use the self-relative binary format defined in MS-DTYP section 2.4.6, ensuring compatibility with Active Directory and Samba environments.

ACL (Access Control List): An ordered list of ACEs. Two kinds exist: the DACL (controls access) and the SACL (controls audit, mandatory integrity, resource attributes, and central access policy references).

DACL (Discretionary Access Control List): The ACL that defines access rules. An empty DACL denies all access. A NULL DACL (absent) grants all access.

SACL (System Access Control List): The ACL that defines system-level policy -- audit rules, mandatory integrity labels, resource attributes, and scoped policy references. Modifying the SACL requires ACCESS_SYSTEM_SECURITY.

ACE (Access Control Entry): A single rule within an ACL. Contains: a type discriminator, flags, an access mask, a SID, and optionally GUIDs (for object ACEs) or application data (for conditional and resource attribute ACEs). Types include: access allowed/denied (basic and callback/conditional), object ACEs (with property/property-set GUIDs), audit/alarm ACEs, mandatory integrity labels, resource attributes, scoped policy IDs, and process trust labels.

AccessCheck: The complete authorization evaluation function. Takes a token (subject), a Security Descriptor (object policy), and a desired access mask. Returns the set of granted rights or denial.

Access mask: A 32-bit bitmask representing requested or granted access rights. Divided into: object-specific rights (bits 0--15), standard rights (bits 16--20), special rights (bits 24--25), and generic rights (bits 28--31).

Privilege: A system-wide right carried on a token that gates specific operations. Some privileges influence AccessCheck; others gate standalone operations.

Impersonation level: Controls how far a token's identity can travel. Four levels: Anonymous, Identification, Impersonation, Delegation.

Integrity level: A vertical trust classification on tokens and objects. Five levels forming a strict total order: Untrusted < Low < Medium < High < System.

MIC (Mandatory Integrity Control): A mandatory access constraint evaluated before the DACL. Blocks write access (and optionally read/execute) when the caller's integrity level is below the object's mandatory label.

PIP (Process Integrity Protection): A 2D trust model (type x trust level) that protects objects and processes from access by insufficiently trusted processes. Unlike MIC, PIP revokes privilege-granted rights.

PSB (Process Security Block): A per-process security structure carrying PIP identity, process mitigations, and process restrictions. The PSB is never affected by impersonation.

FACS (File Access Control Shim): The KACS subsystem that replaces Linux DAC with SD-based evaluation on files. Enforces the handle model: AccessCheck runs at open time, the granted mask is cached on the file descriptor, and subsequent operations check the cached mask (with limited exceptions documented in the use-time semantics, e.g., v0.20 execveat uses live AccessCheck).

Principal: A user, group, service, or machine -- an entity that can be identified. Principals exist in a directory; tokens are runtime snapshots of principal identity.

Object type: The category of a protected resource. Each object type defines a GenericMapping table that translates generic access rights to object-specific rights.

TCB (Trusted Computing Base): The set of components whose correct behaviour is necessary for system security. In Peios: the Linux kernel, PKM, and core trusted userspace daemons (peinit, authd, loregd).

LSM (Linux Security Module): The kernel framework that KACS builds on. LSM provides hook points throughout the kernel where security modules interpose access control decisions.

LogonSession: A kernel object representing a single authentication event. Contains: session ID, logon type, user SID, authentication package, logon time, and a logon SID. Tokens reference their LogonSession by ID.

§1.3 1 Introduction

Conventions

This specification uses the key words MUST, MUST NOT, SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, REQUIRED, and OPTIONAL as described in RFC 2119.

ⓘ Informative
"MUST" and "SHALL" indicate absolute requirements. "MUST NOT" and "SHALL NOT" indicate absolute prohibitions. "SHOULD" indicates a recommendation that may be departed from in particular circumstances with full understanding of the implications. "MAY" indicates a truly optional feature.

Pseudocode in this specification uses the following conventions:

  • & as a parameter prefix denotes an in-out parameter (the caller's value is read and may be modified).
  • | in expressions denotes bitwise OR.
  • & in expressions denotes bitwise AND.
  • ~ denotes bitwise NOT.
  • denotes function return type.
  • // introduces a comment.
  • Assignment is =. Augmented assignment is |=, &=.
  • All access masks are 32-bit unsigned integers unless otherwise stated.
  • SID comparison is byte-for-byte equality of the binary encoding.

Section references within this specification use page titles (e.g., "see the Token Access Rights section").

ⓘ Informative
KACS data structures (SDs, SIDs, ACEs, access masks) use binary formats compatible with Active Directory and Samba, ensuring interoperability in domain environments. Where the KACS evaluation model departs from the behaviour described in MS-DTYP, the divergence is intentional and documented in the Compatibility section.
§1.4 1 Introduction

Compatibility

KACS is the security model of Peios. It is not a port or reimplementation of any other system's security model. The design choices -- tokens, Security Descriptors, AccessCheck, structured SIDs, per-thread impersonation -- were made because they solve the problems Peios needs solved: coherent identity, rich per-object access control, scoped delegation, and integrated audit.

These same primitives are used by Active Directory environments. Peios is designed to participate in AD domains as a first-class member: domain-joined Peios machines exchange security data with domain controllers, authenticate via Kerberos, and enforce access policies distributed through Group Policy. This interoperability imposes specific binary format requirements on KACS data structures.

§1.4.1 Format compatibility

The following data structures MUST use the binary formats specified by MS-DTYP, ensuring byte-level compatibility with Active Directory and Samba:

  • Security Identifiers (SIDs) -- same binary encoding, same comparison rules, same well-known values.
  • Security Descriptors -- self-relative binary format (MS-DTYP section 2.4.6). An SD from a Windows domain controller, replicated through Samba 4, is evaluated by KACS without translation.
  • Access Control Entries -- same ACE types, same header format, same access mask layout.
  • Access masks -- same 32-bit layout: object-specific bits 0--15, standard bits 16--20, special bits 24--25, generic bits 28--31.
  • Conditional ACE expressions -- same binary bytecode format (MS-DTYP section 2.4.4.17).

§1.4.2 Evaluator compatibility

Given the same token, SD, and desired access mask, KACS SHOULD produce the same access decision as described in MS-DTYP for the standard evaluation model. This ensures that access policies authored in AD environments -- file permissions set via Group Policy, object ACLs on directory entries, central access policies -- behave predictably on Peios machines.

Where Peios departs from the MS-DTYP evaluation model, the divergence is intentional and documented. The following table lists all intentional divergences:

Area Divergence Rationale
Conditional ACE @Local. Resolved from an AccessCheck parameter, not a token field Per-call context that varies between access checks
Virtual groups in expressions Member_of({S-1-3-4}) returns TRUE for the owner Semantic consistency between SID matcher and expression evaluator
INT64/UINT64 promotion Relational operators promote between INT64 and UINT64 Without promotion, UINT64 claims are unusable in conditions
Member_of filtering Filters by ACE polarity; deny-only groups do not satisfy allow-ACE conditions Consistent with deny-only group semantics
Exists scope Extended to all four attribute namespaces No reason to restrict existence tests to Local and Resource
ACE mask mapping ACE masks are mapped via GenericMapping at evaluation time Required for central access policy GENERIC_ALL in recovery ACEs
MAXIMUM_ALLOWED semantics Uses first-writer-wins for both targeted and MAXIMUM_ALLOWED requests Eliminates desync between "what can I do?" and "can I do this?"
Zero desired mask Succeeds (not ACCESS_DENIED) "Asked for nothing, got nothing" is a valid answer
Alarm ACEs Repurposed for continuous per-operation auditing Reserved but never implemented in the reference model
Multiple scoped policy ACEs Allowed per SACL AND semantics make composition safe
Mandatory policy mutability mandatory_policy is immutable on the token Mutable policy reduces MIC to advisory
Impersonation integrity ceiling Unconditionally enforced; SeImpersonatePrivilege does not bypass it MIC is a real boundary when mandatory_policy is immutable
Impersonation origin check Dropped Eliminates hidden impersonation paths
PIP determination Kernel-only, from binary signature; no parent input One input, one answer, no ambiguity
Object type list validation Rejects duplicate GUIDs and level gaps Prevents FindNode returning the wrong node
Composite equality Element-wise ordered comparison Never over-grants

§1.4.3 Features handled by other subsystems

The following features relevant to a complete security posture are not part of KACS. They are handled by other Peios subsystems.

Feature Subsystem
Kerberos / NTLM authentication authd
S4U (Service-for-User) authd
Credential storage and protection authd
Active Directory replication Samba 4
Group Policy distribution Registry / roles
Network share permissions Samba SMB layer
Resource-Based Constrained Delegation KDC (authd)
Authentication Policies and Silos KDC (authd)
Encrypting File System Future service