[Security Review] Daily Security Review & Threat Model — 2026-05-17

[github-actions[bot]]

📊 Executive Summary

This review covers the gh-aw-firewall (AWF) codebase as of 2026-05-17. The system implements a layered defense model: host-level DOCKER-USER iptables rules, container-level NAT/filter chains, a Squid L7 proxy, capability dropping, chroot isolation, and seccomp confinement. The overall security posture is strong with well-structured, defense-in-depth controls. No critical vulnerabilities were identified. A small number of medium/low-severity design-level observations are documented below.

Key metrics:

• ~414 lines of seccomp profile (containers/agent/seccomp-profile.json)
• ~420 lines of iptables setup (containers/agent/setup-iptables.sh)
• ~200+ lines of entrypoint with explicit UID/GID validation (containers/agent/entrypoint.sh)
• 24 dangerous ports explicitly blocked (src/squid/policy-manifest.ts:10–32)
• Domain injection validated via SQUID_DANGEROUS_CHARS regex (src/domain-patterns.ts:27) and assertSafeForSquidConfig() (src/squid/domain-acl.ts:28)

---

🔍 Findings from Firewall Escape Test

The pre-fetched escape test file (/tmp/gh-aw/escape-test-summary.txt) contained CI workflow execution metadata rather than test findings — it appears to be logs from a "Secret Digger (Copilot)" run that ended with GH_AW_SECRET_VERIFICATION_RESULT: success and GH_AW_AGENT_CONCLUSION: success. The agent emitted only a noop output, indicating no secrets were found/exfiltrated during that run. This is consistent with the credential isolation mechanisms verified in the codebase below.

---

🛡️ Architecture Security Analysis

Network Security Assessment

Evidence collected:

• containers/agent/setup-iptables.sh (full review)
• src/host-iptables-rules.ts (host-level DOCKER-USER chain setup)

Findings:

1. IPv6 egress disabled (setup-iptables.sh:~50-55):

   sysctl -w net.ipv6.conf.all.disable_ipv6=1
   sysctl -w net.ipv6.conf.default.disable_ipv6=1

   IPv6 is disabled inside the agent container to prevent bypassing the IPv4-only DNAT rules. This is a critical mitigation against Happy Eyeballs / dual-stack bypass.

2. Dual-layer enforcement (NAT + FILTER): Port 80/443 traffic is DNAT'd to Squid at layer 3, and then Squid enforces domain ACLs at layer 7. Any proxy-unaware tool that ignores HTTPS_PROXY will have its TCP stream rejected with a TLS error at Squid — still blocked, just with a different error.

3. DNS restriction: resolv.conf is overwritten to only list 127.0.0.11 (Docker embedded DNS). Direct UDP/TCP port 53 to non-configured servers is blocked by the OUTPUT filter chain. This prevents DNS-based data exfiltration.

4. Dangerous port blacklist (src/squid/policy-manifest.ts:10): 24 ports covering SSH, SMTP, databases, Redis, MongoDB, RDP, etc. are blocked both at Squid and at the iptables NAT level.

5. Observation (Medium): The AWF_ENABLE_HOST_ACCESS flag causes setup-iptables.sh to add blanket NAT RETURN rules for both host.docker.internal and the NETWORK_GATEWAY_IP. This means any TCP traffic destined for the host gateway fully bypasses Squid for L7 inspection. Port restrictions (--allow-host-ports) apply only to the FILTER chain, so HTTP/HTTPS traffic to the host is permitted but unlogged at the L7 level. This is a deliberate design tradeoff (MCP servers need this), but it means L7 audit coverage has a gap when host access is enabled.

6. Observation (Low): setup-iptables.sh parses AWF_DNS_SERVERS from the environment without validation beyond basic IP format checking. A malformed IPv6 address with shell metacharacters could potentially escape — but since the value originates from the TypeScript CLI which performs its own validation, the risk is low in practice.

Container Security Assessment

Evidence collected:

• containers/agent/entrypoint.sh (full review)
• containers/agent/seccomp-profile.json (414 lines)
• Grep for capsh, cap_drop, NO_NEW_PRIVS

Findings:

1. UID/GID validation (entrypoint.sh:~14-32): Explicit numeric regex check and prohibition of UID=0/GID=0 prevents privilege escalation through AWF_USER_UID/AWF_USER_GID environment variables.

2. Capability drop (entrypoint.sh:~927): capsh --drop=<caps> drops capabilities from the bounding set before running user code. SYS_CHROOT and SYS_ADMIN are explicitly mentioned in documentation as dropped. This is an irreversible drop from the bounding set.

3. Seccomp profile: containers/agent/seccomp-profile.json at 414 lines implements a syscall allowlist, which is a strong defense against container breakout via kernel exploitation.

4. chroot to /host: User code runs chrooted, limiting filesystem access to explicitly mounted paths. /etc/shadow is excluded. Home directory mounts are limited to a whitelist (.cache, .config, .local, .anthropic, .claude, etc.).

5. procfs with hidepid=2: The container-scoped procfs mounted at /host/proc uses hidepid=2, preventing the agent from reading /proc/[pid]/environ of other processes.

6. Observation (Medium): The entrypoint script runs node inline to update Claude config files (entrypoint.sh:~190-200), e.g.:

   node -e "const fs = require('fs'); const f = process.env.AWF_CONFIG_FILE; ..."

   The AWF_CONFIG_FILE path is derived from $HOME which is an environment variable. If an attacker could influence HOME or AWF_CONFIG_FILE before entrypoint runs, they might redirect the write. However, this runs as root inside the container before the privilege drop, limiting the practical impact. The value is constructed from known paths, not from untrusted input.

7. Observation (Low): capsh availability is checked on the host via chroot /host which capsh. If the host does not have capsh installed, the entrypoint exits with an error (entrypoint.sh:~591-594) — this is the correct fail-safe behavior, but it means AWF is dependent on host tooling for its privilege-drop guarantee.

Domain Validation Assessment

Evidence collected:

• src/domain-patterns.ts (full review)
• src/squid/domain-acl.ts (assertSafeForSquidConfig)

Findings:

1. Squid injection prevention: SQUID_DANGEROUS_CHARS = /[\s\0"';#]/ is checked at parse time (validateDomainOrPattern), and assertSafeForSquidConfig()indomain-acl.ts` provides a defense-in-depth check at interpolation time. Backslash is explicitly rejected for domain names.

2. Wildcard safety: Wildcard patterns (*.foo.com) are converted to regex using wildcardToRegex() with character-class restriction [a-zA-Z0-9.-]* to prevent ReDoS and regex injection.

3. ReDoS protection (domain-patterns.ts:~94): Comment explicitly notes the use of [a-zA-Z0-9.-]* instead of .* to prevent catastrophic backtracking.

4. Observation (Low): The --allow-urls feature uses a different validation path (SQUID_DANGEROUS_CHARS only, without the backslash restriction) because URL regex patterns legitimately use \. This is correct but worth noting as a potential future audit point if URL pattern complexity increases.

Input Validation Assessment

Evidence collected:

• src/commands/validate-options.ts
• src/host-iptables-rules.ts (isValidPortSpec)

Findings:

1. Port specification validation: isValidPortSpec() in host-iptables-rules.ts rejects leading zeros and enforces 1–65535 range. The same logic is mirrored in setup-iptables.sh's is_valid_port_spec(), creating dual-layer validation.

2. No eval or new Function in production code: grep of src/ (excluding tests) found no dynamic code execution patterns.

3. execa used for subprocess execution: The codebase uses execa (not child_process.exec with shell=true) for docker-compose invocations, preventing shell injection via command arguments.

---

⚠️ Threat Model (STRIDE)

Category	Threat	Evidence	Likelihood	Impact	Status
Spoofing	Agent spoofs Squid CA to intercept its own HTTPS traffic	SSL Bump is opt-in; by default Squid uses forward proxy (CONNECT), no SSL inspection	Low	High	Mitigated by default
Spoofing	Malicious domain matches legitimate whitelist via subdomain injection	formatDomainForSquid adds leading dot; assertSafeForSquidConfig rejects special chars	Very Low	High	Mitigated
Tampering	Agent modifies /etc/resolv.conf post-chroot to redirect DNS	resolv.conf is written before chroot; chroot limits write access	Low	Medium	Mitigated by chroot
Tampering	Agent tampers with iptables after init container completes	Agent container does not have NET_ADMIN; only init container does	Very Low	Critical	Mitigated
Repudiation	Agent denies network access attempts	Squid logs all TCP_DENIED/TCP_TUNNEL with timestamps; iptables LOG rules capture non-HTTP	Low	Low	Mitigated
Information Disclosure	Agent reads /proc/[pid]/environ to steal API keys	hidepid=2 on procfs mount prevents this	Low	Critical	Mitigated
Information Disclosure	Agent reads /etc/shadow or unwhitelisted $HOME paths	Selective bind mounts exclude shadow; home dirs use allowlist	Low	High	Mitigated
Information Disclosure	DNS exfiltration via non-standard DNS servers	resolv.conf restricted to 127.0.0.11; OUTPUT chain drops UDP/TCP :53 to non-configured servers	Low	Medium	Mitigated
Denial of Service	Agent saturates Squid proxy with requests	No rate limiting in Squid config; iptables LOG rules use --limit 5/min to protect kernel buffer	Medium	Low	Partially mitigated
Elevation of Privilege	Agent escalates via SYS_CHROOT/SYS_ADMIN capabilities	capsh --drop removes from bounding set before user code; irreversible	Very Low	Critical	Mitigated
Elevation of Privilege	UID 0 injected via AWF_USER_UID=0	Entrypoint explicitly checks and rejects UID/GID of 0	Very Low	Critical	Mitigated
Elevation of Privilege	IPv6 bypass of DNAT rules	sysctl net.ipv6.conf.all.disable_ipv6=1 inside container	Low	High	Mitigated

---

🎯 Attack Surface Map

Surface	Entry Point	Current Protections	Risk
CLI domain arguments	src/domain-patterns.ts:validateDomainOrPattern	SQUID_DANGEROUS_CHARS + backslash rejection + assertSafeForSquidConfig at interpolation	🟢 Low
CLI port arguments	src/host-iptables-rules.ts:isValidPortSpec	Numeric regex, range validation, leading-zero rejection	🟢 Low
Squid proxy (HTTP)	Port 80 DNAT → Squid:3128	Domain ACL allowlist; TCP_DENIED on non-whitelisted	🟢 Low
Squid proxy (HTTPS)	HTTPS_PROXY env + DNAT fallback → Squid:3128	CONNECT method + SNI-based ACL; TLS error for proxy-unaware tools	🟡 Medium (proxy-unaware HTTPS gets TLS error, not 403)
DNS	resolv.conf + OUTPUT chain	Only 127.0.0.11 in resolv.conf; UDP/TCP :53 drop for non-configured servers	🟢 Low
Host gateway bypass	AWF_ENABLE_HOST_ACCESS flag	NAT RETURN for host gateway; FILTER limits to specified ports	🟡 Medium (L7 audit gap)
Container filesystem	Bind mounts under /host/	Selective mounts; /etc/shadow excluded; home uses allowlist	🟢 Low
procfs	/host/proc	hidepid=2 prevents cross-process environ reads	🟢 Low
Capabilities	Linux capabilities after entrypoint	capsh --drop from bounding set; seccomp profile (414-line allowlist)	🟢 Low
API proxy sidecar	`(172.30.0.30/redacted) (agent-visible)	No auth needed from agent side (by design); sidecar injects real keys; Squid enforces upstream domain	🟡 Medium (any agent code can call the proxy)
Environment variables	AWF_USER_UID, AWF_USER_GID, AWF_CONFIG_FILE etc.	Numeric validation; UID=0 rejected; values constructed from known paths	🟢 Low

---

✅ Recommendations

🔴 Critical

None identified.

🟠 High

None identified.

🟡 Medium

1. Document the L7 audit gap for host-access mode: When --enable-host-access is used, HTTP/HTTPS traffic to the host gateway bypasses Squid and is not logged at L7. Consider adding a warning in the CLI output and in documentation when this flag is enabled, so users understand the audit coverage reduction.

2. Consider rate-limiting Squid connections: The current Squid config does not include connection rate limits (max_connections, delay_pools). A runaway or adversarial agent could flood Squid or exhaust host TCP connections. Adding max_connections 500 or a delay_pool for the agent IP would mitigate DoS scenarios.

3. API proxy sidecar access is implicit: When --enable-api-proxy is active, any process in the agent container can call `(172.30.0.30/redacted) and receive an authenticated response. There is no per-process or per-credential token binding. This is a deliberate design choice (the agent is the trusted party), but if an agent is compromised and can spawn subprocesses, those subprocesses inherit API access. Consider documenting this trust boundary explicitly.

🟢 Low

4. capsh host dependency: The privilege-drop guarantee depends on capsh being present on the host (/host/usr/sbin/capsh or equivalent). Consider either bundling capsh in the agent container image (avoiding the host dependency) or providing a more informative error message that includes remediation steps.

5. Shell variable injection in setup-iptables.sh: AWF_DNS_SERVERS is split with IFS=',' and iterated. Each element is trimmed with tr -d ' ' but not validated against an allowlist before being used in iptables -d "$dns_server". While TypeScript validates this before passing it to Docker, adding IP format validation in the shell script as well would make the script safe to run standalone.

6. --allow-urls backslash exception: URL regex patterns allow \ (backslash) through SQUID_DANGEROUS_CHARS validation (intentionally). Ensure this exception is documented in the security model and that the Squid regex engine's behavior with attacker-influenced backslash sequences is periodically audited.

---

📋 Evidence Collection

Key files reviewed

• containers/agent/setup-iptables.sh — ~420 lines, full review
• containers/agent/entrypoint.sh — full review (UID validation, DNS config, SSL Bump, iptables wait, capsh drop)
• containers/agent/seccomp-profile.json — 414 lines
• src/domain-patterns.ts — SQUID_DANGEROUS_CHARS, validateDomainOrPattern, wildcardToRegex
• src/squid/domain-acl.ts — assertSafeForSquidConfig, formatDomainForSquid
• src/squid/policy-manifest.ts — DANGEROUS_PORTS (24 ports listed)
• src/host-iptables-rules.ts — isValidPortSpec, setupHostIptables, DOCKER-USER chain setup
• src/domain-patterns.ts — ReDoS protection comment, wildcard character class restriction

Commands run

# Escape test pre-fetch
cat /tmp/gh-aw/escape-test-summary.txt

# Network security
cat containers/agent/setup-iptables.sh
grep -rn "DANGEROUS_PORTS" src/ containers/ --include="*.ts" --include="*.sh"

# Container security
cat containers/agent/entrypoint.sh | head -200
grep -rn "capsh|cap_drop|NO_NEW_PRIVS|seccomp" containers/ --include="*.sh" --include="*.json"

# Domain validation
cat src/domain-patterns.ts | grep -A20 "validateDomainOrPattern"
cat src/squid/domain-acl.ts | head -100

# Input validation
grep -rn "eval|Function|new Function" src/ --include="*.ts"
grep -rn "execa|spawn|shell|exec" src/cli.ts src/docker-manager.ts

# Policy manifest
cat src/squid/policy-manifest.ts | head -60

---

📈 Security Metrics

Metric	Value
Security-critical TS files analyzed	~12
Shell scripts reviewed	2 (setup-iptables.sh, entrypoint.sh)
Attack surfaces identified	11
STRIDE threats catalogued	12
Critical findings	0
High findings	0
Medium findings	3
Low findings	3
Dangerous ports blocked	24
Seccomp profile syscall entries	~414 lines

Generated by Daily Security Review and Threat Modeling · ● 4.8M · ◷

• expires on May 24, 2026, 12:38 PM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-05-24T12:38:19.029Z.

Closed by Workflow