Explore an optional Dogwood authorization layer #287

Problem Statement

Sandlock provides static sandbox profiles and programmable policy_fn callbacks, but reusable authorization rules involving prior approvals, operation history, and time windows currently require application code.

Dogwood provides a Rust library with Cedar-style permit/forbid rules, custom action schemas, and temporal conditions. Investigate which Sandlock policies it can express and how to integrate it without weakening confinement.

Proposed Solution

Explore an optional Dogwood authorization layer in the trusted supervisor and HTTP proxy. Keep Landlock and seccomp as mandatory enforcement boundaries: a Dogwood permit must never override an existing Sandlock denial.

Start with process execution and HTTP requests, defining trusted event fields for executable/arguments and HTTP method/host/path. Evaluate filesystem and network policy mappings separately, preserving filesystem object semantics and avoiding TOCTOU races.

Keep resource accounting, CPU throttling, COW behavior, mounts, and credential injection in Sandlock configuration and implementation. Dogwood can make decisions using trusted counters, but does not implement those mechanisms. Arbitrary policy_fn callbacks are not automatically translatable into declarative rules.

Dogwood does not compile policies into Landlock or seccomp. Initially evaluate it at selected runtime boundaries; any future static translation should explicitly restrict the supported language subset.

Use Case

• Express HTTP and execution permissions as reusable declarative policies.
• Require a trusted approval event before a sensitive operation.
• Apply request budgets over time, accounting for concurrent requests and denied attempts.
• Explain authorization decisions through structured records identifying applicable rules.

Initial Investigation

• Define action/event schemas and document supported Sandlock policy mappings.
• Prototype execution and HTTP authorization with fail-closed error handling and composition with existing rules.
• Define trusted event production, timestamps, sandbox identity, and request/response ordering. History-based guarantees must state which operations are observed.
• Establish bounded event storage, isolation between sandboxes, restart semantics, policy validation, and decision logging.
• Test denial precedence, concurrency, missing events, and enforcement bypass attempts; measure authorization overhead.

Dogwood explicitly describes its reference interpreter as unsuitable for direct production authorization without additional safeguards. Evaluate these requirements before enabling it outside an experimental integration: security considerations.