2 Commits

Include renames

Author	SHA1	Message	Date
Cuong Manh Le	4113064680	all: apply the organization's allowed destination IPs in Firewall Mode ... Firewall Mode only permits what ctrld resolved, so an approved service addressed by literal IP - with no DNS lookup to observe - is unreachable, and the only workaround was turning the mode off. The API now sends the effective per-org list in destination_ips of every resolver-config response. Apply it as a set rather than as additions: each refresh replaces the previous snapshot, so an entry added upstream takes effect and one removed upstream stops bypassing enforcement. This happens inside the refresh handler before its early returns, so scheduled and forced refreshes both carry it, and without a ctrld reload. Entries carry no TTL and survive the allowlist flushes that follow a profile or network change. Track what the API asked for separately from what pf/WFP accepted, because mirroring can fail and the next refresh - carrying an identical list - would compute no delta to retry. The applied snapshot advances only on success, and the difference is retried by the next refresh and by a reconcile every 5 minutes, reported meanwhile as allowed_destinations_pending. Enforcement coming up replaces the whole set rather than adding to it: the macOS table is a persist table that can still hold what a previous run put there. Enforcement is versioned by a generation advanced under the same lock the mirror is called with, so a maintenance worker outliving its run cannot reinstall permits into enforcement that is gone. macOS keeps the set in a second pf table, <ctrld_allowed_dst>; Windows in per-entry WFP permit filters in their own map - apart from the DNS-resolved entries so a flush of those leaves them installed. Linux is unchanged, the mode already fails open there, and devices with Firewall Mode off are unaffected. Lookups binary search sorted per-family address ranges, so the per-connection hot path stays flat at ~40ns rather than growing with the list. Addresses are logged at debug level only: the list is organization network topology, and Info-level logs are persisted and travel in support bundles. Indirect the refresh's fetch and split its handler out of the fetch loop so both refresh paths are driven end to end in tests without an API server.	2026-08-28 14:01:23 +07:00
Cuong Manh Le	171dd0a7e6	fix(firewall): support VM/container egress under macOS Firewall Mode ... macOS Firewall Mode blocked forwarded/NATed VM/container egress: a guest resolves DNS through a path host ctrld does not observe, so the guest-resolved public IP never enters <ctrld_allowed> and the blanket outbound block drops the guest's TCP/443. Make VM/container guests first-class Firewall Mode clients by forcing their DNS through ctrld. The trusted source subnets are the UNION of: - Auto-detected VM/NAT networks (default, no config): interfaces that are up, carry an RFC1918 IPv4 address, and whose VM ownership can be proven either by a vendor-specific name (vnic/vboxnet/vmnet) or by being a bridge* whose member list contains a vendor VM interface (typically vmenet*). Each keeps its ingress interface, and its pf rules are scoped "on <iface>" so an unrelated interface on the same private range is never affected. - service.firewall_forwarded_sources (opt-in): explicit IPv4 CIDRs, matched on the source CIDR alone, for stacks whose ownership cannot be proven. Config adds only; an invalid or non-IPv4 entry is dropped with a warning. Checking bridge membership is what makes the common case work without config. Every vmnet.framework stack - UTM and other Virtualization.framework guests, Docker Desktop, Multipass, Fusion 12.1+ NAT - puts the RFC1918 gateway address on a bridge10x interface and attaches the vendor-named vmenet* interface as an address-less member, so matching on interface name alone never sees them. Membership is the ownership proof a bridge name lacks: macOS shares that namespace with Thunderbolt/aggregated links (ctrld's own tunnel-change code treats bridge0 as physical), and such a bridge has en* members, so it stays untrusted however private its address. Members are read with ifconfig, and only for a bridge that already carries an RFC1918 IPv4 address, so a host with no VM running executes no subprocess. Per source subnet, plaintext DNS (53) is force-routed through ctrld (route-to lo0 -> existing rdr-on-lo0) so guest resolutions are policy-enforced and populate the allowlist; guest egress to allowed IPs is then permitted by the existing <ctrld_allowed> rule. DoT (853) is blocked so guests cannot swap in an alternate resolver. DoH/443 is a documented limitation. Rules are emitted strictly per address family. Sources are IPv4 (interception targets ctrld's IPv4 listener), so only inet rules are generated: pf rejects an entire anchor over a single "inet6 ... from 192.168.x.0/24" mismatch, which would take DNS interception down with it. Guest IPv6 DoT is covered by the blanket IPv6 block instead, since such a resolver never enters <ctrld_allowed>. firewall_forwarded_sources is deliberately not validated with `cidr`. Entries are checked where they are parsed and a bad one is dropped while the rest of the set still applies. A hard validator would make one typo in an MDM-pushed subnet fatal at startup - validateConfig exits the process - taking DNS service down for the whole host over a line that only ever widened a firewall allowance. The warning fires when the set of unusable entries changes rather than on every parse, since config is re-read on every anchor build and every watchdog tick. Reconcile the trust set at runtime, since VM interfaces appear and disappear while ctrld runs and no existing path rebuilds an intact anchor for that (ensurePFAnchorActive returns early, checkTunnelInterfaceChanges tracks only tunnels, pfInterceptMonitor rebuilds only after a failed host probe). On a change, rebuild the anchor and drop the pf states of the affected subnets (targeted pfctl -k, not a global state flush), because rules govern only new states: a stopped guest would otherwise keep using states created while it was trusted, and a newly trusted one would keep bypassing interception until its states expired. Reconciliation runs on interface appear/disappear, on network changes, on the delayed post-change re-checks (a VM network often gets its address after its interface appears), and on the pf watchdog tick, which bounds guest start/stop convergence to one interval even with no network event. Convergence is not latched on failure: the applied set advances, and states are killed, only after pf has accepted the new anchor. reloadForwardedSourceAnchor reports write/pfctl failures to the caller, which then keeps the previous set recorded and logs a warning, so the next reconcile retries the same transition instead of going quiet with the old anchor still installed. The whole compare-reload-record sequence is serialized so a watchdog tick and a network change cannot both rebuild or interleave snapshots. Every anchor rebuild records the forwarded-source set it installed, and takes that set as a parameter rather than re-detecting internally. Otherwise a rebuild triggered by something else (tunnel change, watchdog restore, VPN DNS exemptions, forced reload, startup) leaves the snapshot at the older set and the next reconcile "discovers" the same change again: another rebuild, another round of killed guest states, and a transition logged for something already in effect. Passing the set in also means what pf loaded is exactly what gets recorded, so an interface appearing mid-reconcile cannot leave the snapshot describing a set that was never installed. The anchor file is replaced atomically (temp file plus rename). Seven paths rebuild it from timers and network-change callbacks in their own goroutines with no lock between them, and os.WriteFile truncates before writing, so a pfctl -f racing that window could read a partial ruleset and reject the anchor - taking DNS interception down until the next watchdog restore. Report the effective trust set at startup and on every change, naming each subnet's origin ("192.168.64.0/24 (configured)" vs "(auto-detected on bridge100)"), and say so explicitly when the set is empty, including what auto-detection requires. Configured entries previously produced no log output at all, so an admin who set firewall_forwarded_sources could not confirm it had taken effect without reading pf rules. Per-source detection logging is at debug, since detection re-runs on every anchor build. Explicit, per-subnet trust boundary (RFC1918-only auto-detect, proven VM ownership, interface-scoped rules, config adds only), not an interface-wide permit: direct public IPs the guest never resolved through ctrld stay blocked. Tests cover rule generation and its interface scoping, the no-blanket-permit boundary, single-family emission (no inet6 rule for an IPv4 source, IPv6 sources skipped), a real pfctl -n -f parse of both the forwarded-source rules alone and the full anchor (group-scoped rules stripped, since _ctrld exists only where the service is installed), invalid/duplicate/non-IPv4 config entries, that a bad entry does not fail config validation, the union set and its signature, a deterministic guest start/stop lifecycle asserting both the rebuild points and which subnets' states must be dropped, anchor-reload failure followed by a successful retry, that reconcile is inert outside firewall mode, ifconfig member parsing against real bridge output, and the trust decision per interface - including everything that must NOT qualify: a Thunderbolt bridge, a public-range VM bridge, an IPv6-only bridge, an address-less vendor interface, a physical uplink and a VPN tunnel. docs/firewall-mode.md documents the boundary, what auto-detection can and cannot prove, the address-family constraint, the lifecycle/retry behavior, how to confirm the trust set from the log, and that a resolver running inside the guest is not supported (its encrypted upstream leaves the host nothing to allowlist).	2026-08-04 14:12:15 +07:00