Security mechanisms and policy boundaries

Guide index · Architecture

XNU security is distributed across object ownership, authorization checks, executable validation, and protected execution interfaces. There is no single function that decides whether an operation is allowed. A syscall may first validate its arguments and descriptor, evaluate Unix credentials, invoke MAC policy callbacks, and finally enter a VM or IPC operation with additional checks. Which checks run depends on that operation and the build configuration.

This chapter describes the xnu-12377.121.6 source in this folder. It distinguishes mechanisms implemented here from policy modules, libraries, firmware, and services reached through interfaces. The presence of a callout does not reveal the complete policy implemented by its provider.

Mermaid source

flowchart TD
    U[Syscall / Mach request / executable load] --> O[Resolve referenced kernel objects]
    O --> C[Credentials and kauth checks]
    O --> M[MAC framework callbacks]
    U --> S[Signature registration and trust decisions]
    S --> V[VM page integrity and mapping enforcement]
    C --> A[Operation implementation]
    M --> A
    A --> R[Selected audit record and result]
    O --> E[Exclaves resource and service authorization]
    E --> X[External execution plus XNU upcalls]

The diagram identifies relationships, not a mandatory ordering of checks for every API.

For the storage behind signed-file policy, read code-signature blob storage: RO wrapper allocation, serialized byte ownership, pointer reconstruction, PAC preparation, borrowed/retained access, permitted field writes and cleanup. The UBC/pager companion supplies its enclosing vnode/VM lifetime.

Reading routes

The structure companions follow credential values and writable lifetime state, MAC label slots and ownership, and thread identity in thread_ro. Read them beside the operation chapters below to connect authorization inputs to allocation, protected updates, references, publication and cleanup. Ports and kobject associations supplies the corresponding storage and conversion model for Mach capabilities.

Executable-memory policy connects MAP_JIT admission and protection changes to monitor association, ARM64 faults and SPTM frame types. It distinguishes current permissions, maximum permissions, entry classification and the physical mapping that a later access obtains.

Two operation companions connect identity and execution state: exec identity and inherited state follows credentials, IPC reset and token publication, while ARM64 thread-state conversion follows kernel-selected import policy, pointer authentication, exception/signal replies and final saved-state writes. Message integrity explains the separate kmsg signature and descriptor-pointer mechanisms.

For an initial source walk, follow setuid() through kauth_cred_proc_update(), then read MAC_CHECK, ubc_cs_blob_add(), cs_validate_hash(), and audit_syscall_enter()/audit_commit(). These paths demonstrate identity replacement, policy composition, integrity metadata, and asynchronous accounting without requiring every security hook to be read first.

Main structures and boundaries

CONFIG_MACF, CONFIG_AUDIT, CONFIG_CSR, CONFIG_CSR_FROM_DT, and CONFIG_EXCLAVES materially change these paths; declarations are in config/MASTER. Code-signing monitor and architecture options introduce additional branches. This chapter is not a statement that every mechanism is active on every product built from XNU.

Sources inspected and limits

Follow process lifecycle for exec and credentials, executable loading for Mach-O parsing, VFS authorization for pathname permissions, VM for page faults, IPC for ports and rights, networking for socket policy, drivers for user clients, and platform for protected memory and boot mechanisms.