source: advance the checked projection
Source-Sha: 194a59adfd6c901635da7a9c18253bb2210e2426 Policy-Sha: b9b0be0ee74e55f561a803b8aef6be3c2134f5a83b46816a069a372f2eb04f4d Tree-Digest: 4697f2e281c1c6ecafff17cf6eeb391a0a1ac0fa6e5fc429f5b473f4579c252c
This commit is contained in:
Source publisher
parent
0401c76c79
commit
ffdccba10f
42 changed files with 2516 additions and 554 deletions
|
|
@ -16,7 +16,12 @@ RedFlag's supply chain gate inverts the traditional defense model: instead of **
|
|||
token. Standalone pacman approval uses a signed `MutationEnvelope`, exact closure archives,
|
||||
detached package signatures, helper custody, and a joined receipt. Docker, Winget, and
|
||||
Windows Update still use the signed-command path. Fleet pacman envelope delivery and kernel
|
||||
enforcement against out-of-band root mutation are not wired.
|
||||
enforcement against out-of-band root mutation are not wired. The native Windows Helper
|
||||
can verify binaries and mutation envelopes but refuses mint and backend execution. A fixed
|
||||
task transport now joins Agent requests to Helper results using handle-relative custody and
|
||||
installer-owned authority selection. It has no admitted Windows mutation backend and lacks
|
||||
native acceptance; service privilege migration and execution remain open. Verification does
|
||||
not consume replay authority. See [Helper invocation](../components/04-helper.md).
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -51,12 +56,12 @@ the unprivileged agent-side consumer. Its *role* as a runtime allow/deny RPC is
|
|||
|
||||
### Why this model (two tests it has to pass)
|
||||
|
||||
**Cross-platform.** Linux eBPF and macOS ESF can pause an exec and ask a daemon "may this
|
||||
proceed?" Windows WDAC cannot — it is signature-based, with no runtime callback. A
|
||||
decision-daemon model therefore has no Windows mapping. A capability token maps onto all
|
||||
three identically: in every case the enforcement layer only needs to answer "is this
|
||||
execution authorized," and a verified token + a privileged executor that the OS trusts is
|
||||
platform-agnostic. We build for the platform with the tightest constraint.
|
||||
**Cross-platform.** Linux eBPF and macOS ESF can observe or mediate execution at a kernel
|
||||
boundary. Windows App Control (WDAC) instead decides which code may execute from policy; it
|
||||
does not authorize one package transaction or protect every file and registry mutation that
|
||||
an already-trusted process can make. The common primitive is the signed mutation
|
||||
authorization consumed by a privileged executor. Platform enforcement narrows bypasses
|
||||
around that executor, but each platform must state exactly what its kernel mechanism covers.
|
||||
|
||||
**Protects people.** Protection comes down to where the trust root lives. The signing key
|
||||
lives at the server (the human-approval authority), off the host. An attacker who fully owns
|
||||
|
|
@ -76,12 +81,15 @@ The two tests converge on the same answer, which is the signal it's right.
|
|||
| Platform | Enforcement Mechanism | What It Blocks |
|
||||
|----------|----------------------|----------------|
|
||||
| **Linux** | eBPF (syscalls/sys_enter_execve) or AppArmor | apt, dnf, yum, pip, npm, bun, docker (CLI) |
|
||||
| **Windows** | WDAC (Windows Defender Application Control) | winget, npm.cmd, pip.exe, choco, scoop |
|
||||
| **Windows** | App Control (WDAC) for executable trust; RedFlag kernel driver for covered mutation transactions | Untrusted mutation code; covered file/registry writes when the driver exists |
|
||||
| **macOS** | Endpoint Security Framework (ESF) | brew, pip, npm, bun, cargo |
|
||||
|
||||
**Target distinction:** kernel enforcement sits below userspace wrappers. The current eBPF
|
||||
scaffold is not connected to the capability model, so RedFlag does not yet claim that an
|
||||
out-of-band package-manager invocation is blocked.
|
||||
**Target distinction:** App Control and transaction enforcement are different Windows
|
||||
layers. WDAC constrains executable trust; it does not prove that trusted code performed an
|
||||
authorized RedFlag transaction. SEC-030 owns the driver and transaction context needed to
|
||||
deny covered file and registry mutations outside a verified envelope. Neither that driver
|
||||
nor the current Linux eBPF scaffold is connected to the capability model, so RedFlag does
|
||||
not yet claim kernel-level blocking on either platform.
|
||||
|
||||
### Trust Chain
|
||||
|
||||
|
|
@ -252,9 +260,10 @@ The token extends the existing Ed25519 infrastructure rather than introducing ne
|
|||
verifies the local Arch keyring, and refuses downgrades or operation-name lies. Legacy
|
||||
registry entries without local paths are not rehashed. The current unit is not
|
||||
network-isolated.
|
||||
- **Kernel layer (where applicable).** Linux eBPF / Windows WDAC / macOS ESF deny
|
||||
package-manager execution except via the trusted executor. This is defense-in-depth design;
|
||||
the present eBPF scaffold is not wired to the capability model.
|
||||
- **Kernel layer (where applicable).** Linux eBPF and macOS ESF mediate covered execution.
|
||||
Windows WDAC constrains executable trust, while a separate RedFlag driver is required for
|
||||
covered transaction writes. This is defense-in-depth design; none of these transaction
|
||||
enforcement paths is wired to the capability model today.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -283,9 +292,10 @@ runtime evidence support them.
|
|||
rotated, replicated, or held by a federation/guild node without touching the agent↔helper
|
||||
interface. This is the long-term cross-platform answer hidden in a one-line design choice.
|
||||
5. **Kernel stops are defense-in-depth, not a prerequisite.** The capability model protects on
|
||||
a host where eBPF/WDAC/ESF cannot be deployed (locked-down managed box, constrained
|
||||
container). Kernel enforcement raises the cost of bypass; it does not gate whether the model
|
||||
means anything. Partial deployment still moves a host out of the soft-target category.
|
||||
a host where eBPF, a Windows transaction driver, or ESF cannot be deployed (locked-down
|
||||
managed box, constrained container). Kernel enforcement raises the cost of bypass; it does
|
||||
not gate whether the model means anything. Partial deployment still moves a host out of the
|
||||
soft-target category.
|
||||
6. **No doctrinal knobs.** Signing required and forward-only (no downgrade) are ETHOS doctrine,
|
||||
not configurable. The token has no "skip verification" path.
|
||||
|
||||
|
|
@ -476,8 +486,9 @@ and kernel adapters remain.
|
|||
|
||||
## Footer: Assumptions & Connections
|
||||
|
||||
**Assumption:** The capability model is the floor; kernel-level primitives (eBPF, WDAC, ESF)
|
||||
are defense-in-depth on top, not a prerequisite. Userspace wrappers alone are bypassable.
|
||||
**Assumption:** The capability model is the floor; kernel-level transaction primitives
|
||||
(eBPF, a Windows driver, ESF) are defense-in-depth on top, not a prerequisite. WDAC is a
|
||||
separate executable-trust layer. Userspace wrappers alone are bypassable.
|
||||
|
||||
**Current:** The privileged executor has a narrow argv-only API, no shell, and a stripped
|
||||
environment; the Agent that hands it capabilities is unprivileged and holds no signing key.
|
||||
|
|
@ -494,6 +505,4 @@ the helper unit. Neither property applies globally until each migrated backend p
|
|||
|
||||
---
|
||||
|
||||
*Last reviewed: 2026-09-01*
|
||||
|
||||
*Last reviewed: 2026-08-26*
|
||||
*Last reviewed: 2026-09-14*
|
||||
|
|
|
|||
Loading…
Reference in a new issue