28 lines
1.7 KiB
Markdown
28 lines
1.7 KiB
Markdown
# TESS-M1-SEC-001 — Command authorization and exact-action approval
|
|
|
|
- Issue/milestone: #707 / M1
|
|
- Branch: `fix/tess-command-authz`
|
|
- Requirement: `TESS-SEC-002`, with approval binding controls from `TESS-SEC-007`
|
|
- Scope: `apps/gateway` only, plus required in-repo security/developer documentation.
|
|
|
|
## Plan
|
|
|
|
1. Locate the gateway command executor, command metadata, authorization context, and existing test conventions.
|
|
2. Write abuse/authz tests before production changes. Expected red cases: non-admin blocked from admin/system command; forged caller scope cannot authorize; privileged/destructive action requires durable exact-action approval; expired/replayed/mutated approvals deny.
|
|
3. Implement server-derived role/scope enforcement and durable approval validation/consumption with audit results.
|
|
4. Run focused security tests, then repository baseline gates: typecheck, lint, format-check, test.
|
|
5. Run independent security/code review, commit, queue-guard, push, and open the PR to `main` through the stated Gitea API fallback. Stop after PR creation.
|
|
|
|
## Assumptions
|
|
|
|
- The existing gateway persistence interface is the available durable approval boundary. If no persistence abstraction exists, a minimal injectable repository interface will be introduced rather than an in-memory approval implementation, because TESS-SEC-002/007 require durable enforcement.
|
|
- “Exact action” is a canonical digest over structured command identity and normalized arguments; role/scope checks always use authenticated server context, not client-declared claims.
|
|
|
|
## TDD evidence
|
|
|
|
- Pending: abuse/authz test written and observed red before implementation.
|
|
|
|
## Verification evidence
|
|
|
|
- Pending.
|