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

Process integrity protection

Concept
Process integrity protection

PIP is the layer of access control that gates operations between processes based on the trust level of their binaries, not the identity of their callers. Each process carries a two-dimensional trust label set by the kernel at exec from the binary's signature. The label is what decides who can signal, inspect, or interfere with the process.

Concept
The process security descriptor

Every running process has its own security descriptor — separate from the security descriptors of its files, its registry keys, or its tokens. The process SD lives on the PSB and gates operations that act on the process itself. This page covers what the process SD contains, the access rights it uses, how it interacts with PIP, and how it is set and modified.

Concept
The two-check rule

Every cross-process operation runs two checks in succession — an SD check against the target's process security descriptor, and a PIP dominance check against the target's PIP label. Both must pass. This page covers the rule itself, the dominance comparison, what SeDebugPrivilege bypasses, and how the rule interacts with specific kernel operations.

Concept
PIP in practice

PIP has a handful of practical interactions that are not obvious from the model alone — its asymmetry with impersonation, why peinit ends up as the lifecycle manager for PIP-protected processes, how it differs from MIC, what its threat-model ceiling is, and the limitations of the v0.20 implementation. This page covers each.