[P1][security] api/rbac.py: middleware default-allow → default-deny + cobertura completa do route-policy map

[FabioLeitao]

U: U1 — a camada de acesso baseada em papéis (Pro+) precisa estar íntegra antes do trabalho da 1.8.0 aterrissar em cima dela (o gate de POST /config do #414 e o WebAuthn dependem dessa base).
G: G2 — weakness funcional/de compliance no controle de acesso. A postura default de bind loopback (127.0.0.1) mitiga a exposição real; o risco materializa em deployments que expõem o dashBOARd e dependem de RBAC como camada de acesso.

Contexto (auditoria 2026-07-02)

O middleware de RBAC (api/rbac.py) resolve a política de acesso a partir de um mapa explícito de rotas protegidas. Rotas que não constam nesse mapa seguem adiante sem verificação (postura default-allow / fail-open). O efeito é estrutural: qualquer rota nova que sirva dados e seja registrada sem entrada correspondente no mapa fica silenciosamente fora da política, sem sinal em CI ou em runtime.

RCA detalhado (rotas afetadas, trechos) está no thread privado da auditoria — este corpo público fica genérico por política de disclosure (repo público).

Fix recomendado

• Inverter a postura para default-deny: manter uma allowlist pública explícita (health, estáticos, etc.) e exigir que toda rota não-pública esteja classificada no mapa RBAC; o não-classificado nega (403) em vez de liberar.
• Garantir cobertura de todas as rotas que servem dados no mapa de política.
• Adicionar teste de invariante: toda rota registrada no app ∈ (allowlist pública ∪ mapa RBAC). O teste falha o CI quando uma rota nova entra sem classificação — fecha o gap na origem.

Não fazer

• Não alterar o comportamento quando o RBAC está desabilitado (default OSS/gratuito) — o escopo é a coerência da política quando o RBAC está ativo.
• Não bloquear rotas públicas de infraestrutura (health/liveness/estáticos).

Critérios de aceite

• Middleware opera em default-deny com allowlist pública explícita.
• Todas as rotas de dados classificadas no mapa RBAC.
• Teste de invariante (rota registrada ⇒ classificada) verde e falhando corretamente quando uma rota nova não é classificada.
• check-all verde.

Milestone sugerido: v1.8.0.
Liga: #86 · #414 · ADR-0033.

Opened by Claude (readonly auditor) — Cursor implements.

[FabioLeitao]

Sugestão de implementação (R.O. auditor — código pra avaliar, não commitado)

Auditei o api/rbac.py no HEAD e o fail-open é exatamente onde a issue aponta: required_roles_for_route() retorna None para DOIS casos distintos (público E desconhecido), e o middleware trata ambos como passa-livre:

req_roles = required_roles_for_route(request.method, request.url.path)
if req_roles is None:
    return await call_next(request)   # passa TANTO publico QUANTO desconhecido (o fail-open)

Fix proposto: sentinela publico explicito (distingue de desconhecido)

Fazer required_roles_for_route retornar PUBLIC_ROUTE (sentinela) para as rotas da allowlist, e reservar None para "desconhecido -> nega":

PUBLIC_ROUTE = "__public__"  # distinto de None
# rotas publicas (health, static, auth/webauthn, about/json, help/about/login) -> return PUBLIC_ROUTE
# catch-all final -> return None (desconhecido)

Middleware trata os 3 casos:

policy = required_roles_for_route(request.method, request.url.path)
if policy == PUBLIC_ROUTE:
    return await call_next(request)               # publico -> passa
if policy is None:
    return JSONResponse(status_code=403,
        content={"detail": "Route not classified in access policy (default-deny)."})  # desconhecido -> NEGA
# classificado -> exige papel (fluxo atual)

O teste de invariante que a issue pede (falha CI se rota nova ficar fora)

tests/test_rbac_route_coverage.py: itera app.routes, e para cada (method, path) verifica que required_roles_for_route NAO retorna None. Placeholders viram x via regex. Comeca informativo (lista as nao-classificadas) e vira hard-gate quando confirmar cobertura total — mesmo padrao do test_claims_consistency.py (feature-gate informativo->hard). Assim nao quebra o CI no 1o run.

Cuidado (honesto)

Ao virar default-deny, rota legitima que sirva dados e NAO esteja no mapa passa a dar 403. Por isso o teste roda PRIMEIRO informativo — pra ver a lista e classificar todas ANTES de ativar o deny. Isto mexe em controle de acesso -> rodar no Maestro (publico ainda acessivel, protegido ainda protegido, novo negado) antes do check-all.

Codigo completo (com o patch do #1134 timing-safe que esta no mesmo arquivo) no pacote de deliverables PATCH_rbac_default_deny_2026-07-05.md. E sugestao — se estiver certo, implementa; se nao, descarta.

— claude.ai · Auditor R.O. externo (steering/altitude) · Sonnet 5 · A.I.I.D.C.O.B.P.P. v1.4