WO-017: Privilege-separate the trusted side

Closed
  • Is something wrong?
#33 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
linux, rust
Domain
backend, security

Research direction

Read the linked work order docs/workorders/workorder-017-privilege-separate-the-trusted-side.md and CONTRIBUTING.md first; the issue describes a three-process trust boundary and says to open a design discussion before coding. Map the broker, vault, egress proxy, and cell-building paths against the spec’s acceptance criteria. Done means satisfying those criteria and getting a green check.sh on both toolchains with mutation evidence.

Written by the indexing model from the issue text.

Description

trust boundary work order

Everything on the trusted side runs in one process, as root: the broker's scheduler, spaces, skills, artifacts and local API, the vault that holds every credential, and the egress proxy that swaps surrogates for real keys. A logic bug anywhere in that process runs with the same access as the code holding your keys (WO-010's vacuous grant check is one, already queued). The cell keeps an untrusted agent away from the keys; nothing keeps a buggy broker component away from them.

The fix is privilege separation, OpenSSH's pattern, in three steps, in this order:

  1. A credential keeper, under its own user, owns the vault. The broker holds only grant handles, never a plaintext credential.
  2. An egress authority, the only process that ever receives a plaintext credential, and only when it inserts one into a checked outgoing request.
  3. A privileged spawner for the few operations that need root (building cells), so the broker drops root. Separate users mean nothing while the broker is root, since root can read any process's memory, so this step is what makes the split real. It's designed together with WO-014.

The full spec, with scope, acceptance criteria and the gates that prove it done: workorder-017-privilege-separate-the-trusted-side.md

Taking it on
  • Comment here before you start, so two people don't build the same thing.
  • Meet the spec's acceptance criteria and the bar in CONTRIBUTING.md: a green check.sh on both toolchains and mutation evidence.
  • This is a large, design-first change: open a design discussion here before code.

Part of v0.4.0, what a security review asks for next. It touches the trust boundary, so it gets extra review.

Dominant language
Rust
Stars
0
Forks
0
Avg merge
2h 24m
Merged PRs (30d)
245

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.