[Security Review] Daily Security Review and Threat Modeling — 2026-04-05

[github-actions[bot]]

📊 Executive Summary

This report covers a deep, evidence-based security review of the gh-aw-firewall codebase. No prior "Firewall Escape Test Agent" workflow was found in the repository history; analysis relies entirely on code inspection.

Overall Security Posture: Strong — The architecture demonstrates mature defense-in-depth thinking with multiple overlapping controls. Four findings are documented below; none are critical.

Metric	Value
Files analyzed	src/host-iptables.ts, containers/agent/setup-iptables.sh, src/squid-config.ts, src/domain-patterns.ts, src/cli.ts, containers/agent/entrypoint.sh, containers/agent/seccomp-profile.json, src/dlp.ts, src/docker-manager.ts
npm audit vulnerabilities	0 critical, 0 high, 0 moderate
Findings	4 (0 Critical, 1 Medium, 2 Low, 1 Informational)

---

🔍 Findings from Prior Firewall Escape Testing

No "firewall-escape-test" or equivalent workflow was found in the repository. The security-review workflow exists but logs were not accessible via the agentic-workflows tool in this environment. All findings below derive from direct codebase analysis.

---

🛡️ Architecture Security Analysis

Network Security Assessment

Strengths:

• Two-layer defense: host-level DOCKER-USER chain + container-level OUTPUT chain
• IPv6 disabled via sysctl inside the container to prevent IPv6 egress bypass
• DNS restricted to Docker embedded DNS (127.0.0.11) only; direct queries to non-whitelisted servers are blocked
• Cloud metadata endpoint (169.254.0.0/16) explicitly blocked in host-level chain
• Multicast and link-local traffic explicitly rejected

Container-level iptables flow (containers/agent/setup-iptables.sh):

NAT OUTPUT chain:
  1. RETURN → localhost (127.x, ::1)
  2. RETURN → Squid IP (prevent redirect loops)
  3. RETURN → API proxy IP
  4. RETURN → host gateway (when --enable-host-access)
  5. RETURN → dangerous ports (bypass DNAT for audit drop)
  6. DNAT 80/443 → Squid:3128
FILTER OUTPUT chain:
  1. ACCEPT → localhost
  2. ACCEPT → DNS (upstream servers)
  3. ACCEPT → Squid
  4. LOG+DROP → TCP (default deny)
  5. LOG+DROP → UDP (default deny)
```

**Host-level chain** (`src/host-iptables.ts`):
```
DOCKER-USER → FW_WRAPPER chain:
  1. ACCEPT ← from Squid (unrestricted outbound for Squid)
  2. ACCEPT ← ESTABLISHED/RELATED
  3. ACCEPT → localhost
  4. ACCEPT → DNS servers
  5. ACCEPT → Squid
  6. REJECT → multicast
  7. REJECT → 169.254.0.0/16 (cloud metadata)
  8. REJECT → UDP
  9. REJECT → all other (catch-all)

ICMP: Not explicitly blocked at the container OUTPUT chain level (only TCP/UDP are dropped). However, the host-level catch-all REJECT in FW_WRAPPER does intercept ICMP from the container bridge. Combined with NET_RAW capability drop (preventing raw socket creation), ICMP tunneling is not practically exploitable.

Container Security Assessment

Capabilities (agent container):

• NET_ADMIN — never granted (handled by separate awf-iptables-init init container)
• NET_RAW, SYS_PTRACE, SYS_MODULE, SYS_RAWIO, MKNOD — explicitly dropped
• SYS_CHROOT, SYS_ADMIN — granted initially, then dropped via capsh before user code runs (chroot mode)

Seccomp profile (containers/agent/seccomp-profile.json):

• Default action: SCMP_ACT_ERRNO (allow-list model)
• Blocks: ptrace, process_vm_readv/writev, kexec_load, init_module, pivot_root, umount, kernel key operations
• Allows (notable): unshare, setns, mount, clone, socket, connect — all standard and required for containerized workloads

One-shot token protection: Credentials are cached in-process via LD_PRELOAD=/usr/local/lib/one-shot-token.so, then unset from the parent shell environment after a 5-second initialization window (sleep 5).

Docker socket: Masked by bind-mounting /dev/null over /host/var/run/docker.sock and /host/run/docker.sock unless --enable-dind is explicitly used (documented as a firewall bypass vector).

Domain Validation Assessment

• validateDomainOrPattern() in src/domain-patterns.ts rejects whitespace, null bytes, quotes, semicolons, backticks, hash characters, backslashes
• Overly-broad patterns (*, *.*, patterns of only wildcards and dots) are explicitly rejected
• Wildcard-to-regex conversion uses [a-zA-Z0-9.-]* (not .*) to prevent ReDoS
• assertSafeForSquidConfig() in src/squid-config.ts provides a second validation pass before Squid config interpolation
• Protocol-prefix parsing ((redacted) https://`) is handled before domain validation

Input Validation Assessment

• All docker/iptables commands use execa() with array arguments (no shell interpolation)
• User command is passed to the container via the Docker Compose command: field, not via shell
• Port specifications validated with isValidPortSpec() (rejects leading zeros, validates range bounds)
• UID/GID validated as numeric and non-zero in entrypoint.sh

---

⚠️ Threat Model

STRIDE Analysis

ID	Category	Threat	Evidence	Likelihood	Impact	Severity
T1	Information Disclosure	Dangerous ports list mismatch between squid-config.ts and setup-iptables.sh creates audit log gap	See Finding F1	Low	Low	Medium
T2	Elevation of Privilege	unshare+setns allowed in seccomp; user namespaces + network namespaces could in theory create bypass	See Finding F2	Low	Medium	Medium
T3	Information Disclosure	DLP scanning is opt-in; credentials in URLs not scanned by default	src/cli.ts:1360 --enable-dlp flag	Medium	Medium	Low
T4	Information Disclosure	One-shot token 5-second timing assumption	containers/agent/entrypoint.sh:765,812	Low	Low	Low
T5	Spoofing	AppArmor disabled (apparmor:unconfined) removes MAC layer; relies entirely on DAC+capabilities	src/docker-manager.ts:1242	Low	Low	Informational
T6	Tampering	--enable-dind mounts real Docker socket, allowing new containers without firewall	src/docker-manager.ts:999-1006	Low (user opt-in)	High	Informational (by design)
T7	Repudiation	FW_BLOCKED_DANGEROUS_PORT audit log omits 6 ports that Squid blocks	See Finding F1	Low	Low	Low

---

🎯 Attack Surface Map

Entry Point	File:Line	What It Does	Current Protection	Risk
--allow-domains CLI flag	src/cli.ts, src/domain-patterns.ts	Sets Squid ACL allowlist	Input validation, dangerous char rejection, overly-broad pattern rejection	Low
--allow-host-ports	src/cli.ts:1337, setup-iptables.sh:320-358	Opens additional ports via DNAT to Squid	Port spec validation, Squid ACL still enforced	Low
--enable-host-access	src/cli.ts:1335, setup-iptables.sh:181-295	Allows traffic to host gateway (80/443 + custom ports)	IP restricted to resolved host gateway only	Low
--enable-dind	src/docker-manager.ts:999-1006	Mounts Docker socket	Documented bypass risk, user must explicitly opt in	High (opt-in)
--allow-host-service-ports	src/cli.ts:782, setup-iptables.sh:250-296	Bypasses dangerous-port blocklist for host-only ports	Limited to host gateway IP, no ranges allowed	Low
API proxy sidecar (--enable-api-proxy)	src/host-iptables.ts:416-428	Allows 10000:10004 range to proxy IP	Restricted to API proxy IP only	Low
Squid AWF_SQUID_CONFIG_B64 env var	src/docker-manager.ts:475-487	Base64 Squid config injected via environment	Config generated by trusted code, not from user input directly	Low
Domain wildcard patterns	src/domain-patterns.ts:96-135	* → Squid dstdom_regex ACL	Safe character class replaces .* to prevent ReDoS	Low
--ssl-bump CA	src/squid-config.ts:138-245	Full HTTPS inspection with generated CA	Per-session ephemeral CA	Medium

---

📋 Evidence Collection

F1: Dangerous ports list mismatch

Command:

python3 -c "
import re

with open('src/squid-config.ts') as f:
    squid = f.read()
# ... extract DANGEROUS_PORTS from both files
"
```

**Output:**
```
In squid (src/squid-config.ts) but NOT in iptables (setup-iptables.sh):
  {5984 (CouchDB), 6984 (CouchDB SSL), 8086 (InfluxDB HTTP), 8088 (InfluxDB RPC), 9200 (Elasticsearch HTTP), 9300 (Elasticsearch transport)}

squid ports: [22, 23, 25, 110, 143, 445, 1433, 1521, 3306, 3389, 5432, 5984, 6379, 6984, 8086, 8088, 9200, 9300, 27017, 27018, 28017]
iptables ports: [22, 23, 25, 110, 143, 445, 1433, 1521, 3306, 3389, 5432, 6379, 27017, 27018, 28017]

Evidence in source:

• src/squid-config.ts:16-30: DANGEROUS_PORTS includes 5984, 6984, 8086, 8088, 9200, 9300
• containers/agent/setup-iptables.sh:303-319: DANGEROUS_PORTS array omits these 6 ports

Assessment: The comment at setup-iptables.sh:305 states "Dangerous ports list - matches DANGEROUS_PORTS in squid-config.ts" but they do not match. The security impact is low because the final iptables -A OUTPUT -p tcp -j DROP still blocks these ports. However:

1. These 6 ports do not generate [FW_BLOCKED_DANGEROUS_PORT] audit log entries (they generate generic [FW_BLOCKED_TCP] instead), creating an audit gap
2. The comment is misleading, creating a maintenance risk where future additions to one list may not be reflected in the other

F2: unshare/setns allowed in seccomp profile

Command:

python3 -c "
import json
d = json.load(open('containers/agent/seccomp-profile.json'))
allowed = [n for sc in d['syscalls'] if sc['action']=='SCMP_ACT_ALLOW' for n in sc['names']]
ns_calls = ['unshare','setns','clone','clone3','mount','pivot_root']
for s in ns_calls:
    print(f'{s}: {\"ALLOWED\" if s in allowed else \"BLOCKED\"}')
"
```

**Output:**
```
unshare: ALLOWED
setns: ALLOWED
clone: ALLOWED
clone3: ALLOWED
mount: ALLOWED
pivot_root: BLOCKED

Assessment: unshare is allowed in the seccomp profile (containers/agent/seccomp-profile.json). In theory, an unprivileged user can call unshare(CLONE_NEWNET) after creating a user namespace (unshare --user --net), placing themselves in a new network namespace where none of the AWF iptables rules apply. This is a known container-in-namespace escape pattern.

Mitigating factors:

• The agent runs as awfuser with no-new-privileges:true after capability drop
• NET_ADMIN is never granted to the agent container
• Without NET_ADMIN, creating a new network namespace with CLONE_NEWNET without an enclosing CLONE_NEWUSER requires privileges the agent doesn't have
• Docker's no-new-privileges flag prevents gaining capabilities via setuid binaries
• User namespaces themselves require that the user's UID be in userns_allowed_uids (kernel-configured)

Residual risk: If the Linux kernel on the runner has unprivileged user namespace creation enabled (kernel.unprivileged_userns_clone=1, which is the default on Ubuntu 22.04), the agent could create a new user+network namespace and bypass firewall rules within that namespace. Network traffic from inside that namespace would still traverse the host network stack where the DOCKER-USER chain applies, but the iptables rules applied to OUTPUT from the container's original network namespace would not apply in the new namespace.

F3: DLP scanning opt-in

src/cli.ts:1360:

'--enable-dlp',
'Enable DLP (Data Loss Prevention) scanning to block credential\n' +

DLP patterns in src/dlp.ts cover GitHub PATs, OpenAI keys, Anthropic keys, AWS access key IDs, Google API keys. These patterns only activate when --enable-dlp is passed. Without it, a compromised agent could exfiltrate API keys embedded in URL query parameters (e.g., ?token=ghp_xxxx) to whitelisted domains.

F4: API proxy port range includes port 10003

src/host-iptables.ts:416-428:

const allPorts = Object.values(API_PROXY_PORTS);  // [10000, 10001, 10002, 10004]
const minPort = Math.min(...allPorts);  // 10000
const maxPort = Math.max(...allPorts);  // 10004
// Adds iptables rule: -p tcp -d apiProxyIp --dport 10000:10004 -j ACCEPT

The iptables port range 10000:10004 includes port 10003, which is not a defined API proxy port. If any service accidentally starts on port 10003 of the API proxy container, it would be reachable from the agent. Impact is limited to the API proxy IP (172.30.0.30) only and only when --enable-api-proxy is used.

---

✅ Recommendations

Medium Priority

M1 — Sync dangerous ports lists between squid-config.ts and setup-iptables.sh
Add the 6 missing ports (5984, 6984, 8086, 8088, 9200, 9300) to DANGEROUS_PORTS in containers/agent/setup-iptables.sh. This ensures audit logs consistently identify these ports as dangerous (not just generic blocked TCP), and validates that the comment "matches DANGEROUS_PORTS in squid-config.ts" is accurate.

# containers/agent/setup-iptables.sh: add to DANGEROUS_PORTS array:
5984   # CouchDB
6984   # CouchDB (SSL)
8086   # InfluxDB HTTP API
8088   # InfluxDB RPC
9200   # Elasticsearch HTTP
9300   # Elasticsearch transport

M2 — Consider blocking unprivileged user namespaces in seccomp
Add a seccomp rule to restrict unshare and clone/clone3 with CLONE_NEWUSER flag. Docker's default seccomp profile blocks clone(CLONE_NEWUSER) for this reason. Currently, unprivileged user namespace creation (if enabled on the host) could allow the agent to create an isolated network namespace.

Alternatively, document that kernel.unprivileged_userns_clone=0 should be set on host runners.

Low Priority

L1 — Enable DLP by default or document credential-in-URL risk
DLP scanning (--enable-dlp) is opt-in but provides important protection against credential exfiltration in URLs. Consider making it the default and providing --disable-dlp as an escape hatch, or add prominent documentation about the risk.

L2 — Use multiport matching for API proxy in host-iptables
Replace the port range 10000:10004 with explicit --dports 10000,10001,10002,10004 using -m multiport to avoid inadvertently allowing port 10003.

// src/host-iptables.ts - replace range with explicit multiport
'-m', 'multiport', '--dports', allPorts.join(','),

L3 — Increase or make configurable the one-shot token initialization window
The 5-second sleep 5 in entrypoint.sh assumes agent initialization (and one-shot-token library caching) completes within 5 seconds. On cold starts with large runtimes (JVM, large Node.js bundles), this window may be insufficient. Consider using a signal file or polling /proc/PID/environ to confirm the token is absent rather than a fixed sleep.

Informational

I1 — Re-enable AppArmor where possible
The agent container uses apparmor:unconfined to allow procfs mounting. Explore whether a custom AppArmor profile can allow mount for procfs while restricting other AppArmor-enforceable behaviors. Removing AppArmor entirely removes a MAC layer that complements DAC and capabilities.

---

📈 Security Metrics

Metric	Value
Security-critical files analyzed	9 source files + 1 JSON profile
Total lines of security code analyzed	~3,000+
Attack surfaces identified	9
STRIDE threats identified	7
Findings	4 (0 Critical, 1 Medium, 2 Low, 1 Informational)
npm audit vulns (0-day)	0
Defense layers (network)	3 (host DOCKER-USER + container OUTPUT + Squid ACL)
Defense layers (credential)	3 (one-shot-token + env unset + DLP optional)

AI generated by Daily Security Review and Threat Modeling

• expires on Apr 12, 2026, 1:51 PM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-04-12T13:51:01.839Z.

Closed by Workflow