dangernoodle-io / breadboard / 30778412858

97%

push

github

feat: add DENY entries to the provisioning-mode HTTP gate (#1212)

bb_http_prov_deny() records narrow (method,path) carve-outs the union
allowlist should not permit even when a broader allow entry matches
(e.g. allowing /api/diag/* while still denying /api/diag/reboot). Deny
is a strict post-filter applied after the union allowlist resolves and
always wins, preserving the gate's existing allow-vs-allow
order-independence guarantee. Denylist entries live in a second,
separate BB_HTTP_PROV_DENYLIST_CAP-sized table, cleared alongside the
allowlist in bb_http_prov_gate_reset().

bb_http_prov_gate_verify_denies() is a composition-time static check
that every deny entry is reachable by some allow entry, catching a
stale or mistyped deny that could never actually gate anything; it is
deliberately not a per-request matched latch (unlike
bb_http_route_exclude_verify()) since deny is evaluated against live
URIs and a latch would false-positive on every cold boot.

Reachability is computed via true prefix-set overlap
(bb_http_prov_gate_entries_overlap()) rather than feeding a deny
entry's own text through bb_route_uri_match() as if it were a
concrete request URI -- that literal-uri-match trick only happened to
work when the deny side carried the (narrower) wildcard; a wildcard
deny under an exact allow (or a wildcard deny broader than a wildcard
allow) was misreported as orphaned even though the live gate correctly
enforced it, making the obvious "fix" for that false orphan -- delete
the deny entry -- a real security regression. Also documents the
allow/deny cap-exhaustion asymmetry (a dropped allow entry fails
closed/safe; a dropped deny entry fails open and callers must treat a
non-BB_OK bb_http_prov_deny() return as fatal) in both the header and
Kconfig help text, and notes that deny's per-method granularity means
a caller carving out a path must deny every method with a matching
allow entry.

B1-1400

8294 of 8858 branches covered (93.63%)

Branch coverage included in aggregate %.

52 of 52 new or added lines in 1 file covered. (100.0%)

14018 of 14173 relevant lines covered (98.91%)

2609.24 hits per line