| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
Some checks failed
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (push) Has been cancelled
The network grant was a `host:port` allowlist checked by name, which is right as far as it goes. But an allowlisted name can resolve, or be rebound, to 169.254.169.254 or to an address on the host's own network, and nothing checked the address actually connected. - SPEC §5.3 rule 4: before every connection the boundary resolves the endpoint and decides on the address. A name reaches only globally routable addresses. For IPv4, unspecified, loopback, private, shared, link-local, IETF protocol block, documentation, benchmarking, multicast and reserved addresses are refused. For IPv6 only global unicast (2000::/3) is reachable, less documentation, Teredo and benchmarking, so a prefix is refused by construction rather than by a list that could miss one. An IPv4 address carried in a mapped, NAT64 or 6to4 address is judged as that IPv4 address, and the cloud metadata services are refused by address, including the one at an otherwise public address. An outbound entry that is itself a literal address names it on purpose and reaches it, and no other. - `Enforcer::may_connect(endpoint, addr)` and `is_global` implement it; the boundary calls `may_connect` with the address it is about to use. - Conformance C2 gains a `connect` vector set and in-code checks. Tests: an allowlisted name never reaches the host's networks (metadata at four addresses, private, loopback, link-local, multicast, mapped, NAT64, IPv4-compatible, 6to4 and Teredo forms), while global addresses in mapped, NAT64 and 6to4 forms are reached; a literal address reaches itself and no other. Four mechanisms switched off in turn (the address check, unmapping, the global-unicast rule, the literal exception), each turned a test red. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| src | ||
| Cargo.toml | ||