Diff: architecture/capability-based-security.es
From 9fca6cd to 9fca6cd
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Capability-based security" | title: "Capability-based security" |
| slug: capability-based-security | slug: capability-based-security |
| category: architecture | category: architecture |
| type: topic | type: topic |
| quality: complete | quality: complete |
| short_description: "Capability-based security is the access-control model PointSav uses at the hardware and operating-system layers, where each software component must hold a mathematically verified cryptographic token to communicate with any other component." | short_description: "Capability-based security is the access-control model PointSav uses at the hardware and operating-system layers, where each software component must hold a mathematically verified cryptographic token to communicate with any other component." |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-04-30 | last_edited: 2026-04-30 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| cites: [] | cites: [] |
| references: | references: |
| - id: 1 | - id: 1 |
| text: "Klein, G. et al. 'seL4: Formal Verification of an OS Kernel.' ACM SOSP, 2009." | text: "Klein, G. et al. 'seL4: Formal Verification of an OS Kernel.' ACM SOSP, 2009." |
| url: "https://dl.acm.org/doi/10.1145/1629575.1629596" | url: "https://dl.acm.org/doi/10.1145/1629575.1629596" |
| - id: 2 | - id: 2 |
| text: "Lampson, B. W. 'Protection.' ACM SIGOPS Operating Systems Review, 8(1):18–24, 1974." | text: "Lampson, B. W. 'Protection.' ACM SIGOPS Operating Systems Review, 8(1):18–24, 1974." |
| url: "https://dl.acm.org/doi/10.1145/775265.775268" | url: "https://dl.acm.org/doi/10.1145/775265.775268" |
| paired_with: capability-based-security.es.md | paired_with: capability-based-security.es.md |
| --- | --- |
| > Capability-based security is the access-control model PointSav uses at the hardware and operating-system layers, where each software component must hold a mathematically verified cryptographic token to communicate with any other component. | > Capability-based security is the access-control model PointSav uses at the hardware and operating-system layers, where each software component must hold a mathematically verified cryptographic token to communicate with any other component. |
| **Capability-based security** is the access-control model that replaces traditional operating-system privilege hierarchies in the PointSav platform. Where conventional operating systems (Windows, macOS, Linux) grant broad permissions through administrative accounts and assume components at the same privilege level can be trusted, capability-based security requires each isolated component to hold an explicit, mathematically verified cryptographic token — called a capability — before it can communicate with any other component. A capability cannot be forged or copied; it is granted by the kernel at process start and revoked when the capability is withdrawn. [^2] This makes the blast radius of any compromise mathematically bounded to the components the compromised process held capabilities for. | **Capability-based security** is the access-control model that replaces traditional operating-system privilege hierarchies in the PointSav platform. Where conventional operating systems (Windows, macOS, Linux) grant broad permissions through administrative accounts and assume components at the same privilege level can be trusted, capability-based security requires each isolated component to hold an explicit, mathematically verified cryptographic token — called a capability — before it can communicate with any other component. A capability cannot be forged or copied; it is granted by the kernel at process start and revoked when the capability is withdrawn. [^2] This makes the blast radius of any compromise mathematically bounded to the components the compromised process held capabilities for. |
| ## Overview | ## Overview |
| Standard operating systems are vulnerable to privilege escalation: a single compromised application can, in many architectures, reach the core memory of the host machine and gain access to other components on the network. The capability model eliminates this class of vulnerability at the architecture level rather than through policy controls. | Standard operating systems are vulnerable to privilege escalation: a single compromised application can, in many architectures, reach the core memory of the host machine and gain access to other components on the network. The capability model eliminates this class of vulnerability at the architecture level rather than through policy controls. |
| The PointSav implementation builds on a microkernel foundation. The microkernel handles only the most primitive routing of physical memory and CPU time. Every driver, network interface, and service process runs in isolated memory, and none holds general administrative rights. To communicate with another isolated component, a process presents a cryptographic capability token. The kernel validates the token and either permits or denies the operation. | The PointSav implementation builds on a microkernel foundation. The microkernel handles only the most primitive routing of physical memory and CPU time. Every driver, network interface, and service process runs in isolated memory, and none holds general administrative rights. To communicate with another isolated component, a process presents a cryptographic capability token. The kernel validates the token and either permits or denies the operation. |
| ## Architecture | ## Architecture |
| The capability layer sits between the seL4 microkernel and the Rust service processes that make up the PointSav Ring 1 and Ring 2 services. The Rust-based capability managers engineer the isolation wrappers and hypervisor bridges that mediate communication between components. | The capability layer sits between the seL4 microkernel and the Rust service processes that make up the PointSav Ring 1 and Ring 2 services. The Rust-based capability managers engineer the isolation wrappers and hypervisor bridges that mediate communication between components. |
| The platform enforces a strict, one-way command flow between isolation domains. An isolated edge delivery process — for example, the MediaKit OS — cannot issue commands back into the secure ToteboxOS vault. If the edge process is compromised, the attacker is contained within the memory sandbox of that process with no capability grants reaching the broader system. The boundary is enforced by the kernel, not by a policy document. | The platform enforces a strict, one-way command flow between isolation domains. An isolated edge delivery process — for example, the MediaKit OS — cannot issue commands back into the secure ToteboxOS vault. If the edge process is compromised, the attacker is contained within the memory sandbox of that process with no capability grants reaching the broader system. The boundary is enforced by the kernel, not by a policy document. |
| ## Properties | ## Properties |
| - **Formal verification.** The seL4 microkernel underlying the capability manager is formally verified in Isabelle/HOL [^1], which means the isolation properties are mathematically proven for the verified configuration — not asserted. | - **Formal verification.** The seL4 microkernel underlying the capability manager is formally verified in Isabelle/HOL [^1], which means the isolation properties are mathematically proven for the verified configuration — not asserted. |
| - **Least privilege by default.** Components start with no capabilities; the system grants the minimum set required for their declared function. Unused capabilities are never held. | - **Least privilege by default.** Components start with no capabilities; the system grants the minimum set required for their declared function. Unused capabilities are never held. |
| - **Blast-radius containment.** Compromise of one component cannot propagate to components it holds no capability grants for. The scope of a breach is bounded at grant time. | - **Blast-radius containment.** Compromise of one component cannot propagate to components it holds no capability grants for. The scope of a breach is bounded at grant time. |
| - **Auditability.** Capability grants are recorded; the set of grants in force at any time is inspectable. There is no hidden administrative path. | - **Auditability.** Capability grants are recorded; the set of grants in force at any time is inspectable. There is no hidden administrative path. |
| ## How It Works | ## How It Works |
| At deployment time, the PointSav capability manager reads a system policy file that declares which processes communicate with which others and what operations each is permitted. The microkernel enforces this policy at runtime: when process A attempts to send a message to process B, the kernel checks A's capability set and either delivers the message or returns a denial. The capability set cannot be modified by the processes themselves — only the capability manager, running with kernel authority, can issue or revoke grants. | At deployment time, the PointSav capability manager reads a system policy file that declares which processes communicate with which others and what operations each is permitted. The microkernel enforces this policy at runtime: when process A attempts to send a message to process B, the kernel checks A's capability set and either delivers the message or returns a denial. The capability set cannot be modified by the processes themselves — only the capability manager, running with kernel authority, can issue or revoke grants. |
| ## Applications | ## Applications |
| The capability model applies across the full PointSav deployment stack: | The capability model applies across the full PointSav deployment stack: |
| - **ToteboxOS** — the primary secure vault OS; all data at rest is accessible only to processes holding the appropriate capability token. | - **ToteboxOS** — the primary secure vault OS; all data at rest is accessible only to processes holding the appropriate capability token. |
| - **MediaKit OS** — the edge delivery environment; deliberately holds no capability grants reaching ToteboxOS, so a compromised delivery node cannot reach stored data. | - **MediaKit OS** — the edge delivery environment; deliberately holds no capability grants reaching ToteboxOS, so a compromised delivery node cannot reach stored data. |
| - **service-fs** — the WORM ledger; append capability is granted to Ring 1 ingest services; no read-modify-write capability exists at the API surface. | - **service-fs** — the WORM ledger; append capability is granted to Ring 1 ingest services; no read-modify-write capability exists at the API surface. |
| ## See also | ## See also |
| - [[sel4-microkernel-substrate]] | - [[sel4-microkernel-substrate]] |
| - [[worm-ledger-architecture]] | - [[worm-ledger-architecture]] |
| - [[3-layer-stack]] | - [[3-layer-stack]] |
| - [[machine-based-auth]] | - [[machine-based-auth]] |
| - [[compounding-substrate]] | - [[compounding-substrate]] |