[Security Review] Daily Security Review and Threat Modeling — 2026-03-25

[github-actions[bot]]

📊 Executive Summary

This review covers a deep, evidence-based analysis of the gh-aw-firewall codebase focusing on the network security architecture, container hardening, domain validation, input sanitization, and token protection mechanisms. No npm dependency vulnerabilities were found (Critical: 0, High: 0, Moderate: 0). Six distinct security issues were identified spanning High, Medium, and Low severity. No active firewall-escape-test workflow logs were retrievable in this run (git not in PATH for the log tool), so findings are based entirely on static codebase analysis.

---

🛡️ Architecture Security Analysis

Network Security Assessment — GOOD with gaps

Evidence gathered:

cat src/host-iptables.ts
cat containers/agent/setup-iptables.sh

The defense-in-depth model is well-designed:

• Host-level DOCKER-USER → FW_WRAPPER chain blocks all container egress except Squid (172.30.0.10) and whitelisted DNS
• Agent-level NAT DNAT redirects ports 80/443 through Squid
• Agent-level OUTPUT filter chain provides a secondary drop layer
• UDP is fully blocked except for whitelisted DNS servers
• IPv6 is disabled via sysctl when ip6tables is unavailable

Gap found: The FW_WRAPPER chain is installed with -I DOCKER-USER 1, which ensures it is evaluated first. However, there is a brief startup window between docker network create and the call to setupHostIptables() where containers on awf-net could make unfiltered outbound connections. This is structurally inherent to the Docker DOCKER-USER approach.

Container Security Assessment — GOOD with one key finding

Evidence gathered:

# From containers/agent/seccomp-profile.json (parsed):
defaultAction: SCMP_ACT_ERRNO
action=SCMP_ACT_ALLOW names=['..., mount, ..., unshare, ..., setns, ...']
action=SCMP_ACT_ERRNO names=['ptrace', 'process_vm_readv', 'process_vm_writev']
action=SCMP_ACT_ERRNO names=['kexec_load', ..., 'mount' NOT blocked here]

# From src/docker-manager.ts:1083-1099
cap_add: ['SYS_CHROOT', 'SYS_ADMIN'],
cap_drop: ['NET_RAW', 'SYS_PTRACE', 'SYS_MODULE', 'SYS_RAWIO', 'MKNOD'],
security_opt: ['no-new-privileges:true', 'seccomp=...', 'apparmor:unconfined']

SYS_ADMIN + SYS_CHROOT are granted to the container for the entrypoint.sh procfs mount, and both are dropped at runtime via capsh before user code runs. However, apparmor:unconfined removes the AppArmor layer, and mount, unshare, and setns are all in the seccomp ALLOW list.

Domain Validation Assessment — STRONG

cat src/domain-patterns.ts

• ReDoS protection: wildcard * converts to [a-zA-Z0-9.-]* (not .*)
• Overly broad patterns (*, *.*, patterns where wildcards ≥ TLD-1 segments) are rejected
• Protocol-specific allowlisting ((redacted) vs https://`) is cleanly implemented
• Input length capped at 512 chars before regex matching

Input Validation Assessment — GOOD

• CLI arguments use execa (array-form, no shell interpolation)
• Shell escaping via escapeShellArg / joinShellArgs in src/cli.ts:867-885
• AWF_USER_UID/AWF_USER_GID validated as numeric and non-zero in entrypoint.sh:10-30
• docker-stub.sh blocks Docker-in-Docker completely with a hard error

---

⚠️ Threat Model (STRIDE)

ID	Category	Finding	Severity	Likelihood	Impact
F1	EoP	API proxy iptables allows port 10003 (range gap)	High	Medium	Medium
F2	EoP	Dangerous port list divergence (6 ports missing from iptables)	High	Medium	Medium
F3	EoP	mount/unshare/setns allowed in seccomp + apparmor:unconfined	Medium	Low	High
F4	Disclosure	5-second token unset race window	Medium	Low	High
F5	Tampering	IPv6 unfiltered if sysctl disable fails silently	Medium	Low	Medium
F6	Bypass	DLP only covers HTTP traffic (not HTTPS without SSL bump)	Low	High	Low

---

🎯 Detailed Findings with Evidence

---

F1 — HIGH: API Proxy Iptables Port 10003 Gap

File: src/types.ts:16-41, src/host-iptables.ts:365-372

Evidence:

// src/types.ts
export const API_PROXY_PORTS = {
  OPENAI: 10000,
  ANTHROPIC: 10001,
  COPILOT: 10002,
  OPENCODE: 10004,   // ← gap: 10003 is not defined
};

// src/host-iptables.ts
const allPorts = Object.values(API_PROXY_PORTS);
const minPort = Math.min(...allPorts);  // → 10000
const maxPort = Math.max(...allPorts);  // → 10004
await execa('iptables', [
  '-t', 'filter', '-A', CHAIN_NAME,
  '-p', 'tcp', '-d', apiProxyIp, '--dport', `\$\{minPort}:\$\{maxPort}`,  // → 10000:10004
  '-j', 'ACCEPT',
]);

Verification:

ports = {10000,10001,10002,10004}
# min-max range: {10000, 10001, 10002, 10003, 10004}
# gap = {10003}

Issue: The min:max iptables port range syntax (10000:10004) allows ALL ports from 10000 to 10004 inclusive, including port 10003. If the API proxy sidecar (172.30.0.30) were compromised or a service were running on port 10003, the agent container could reach it despite the firewall intending to only allow the four defined ports.

Recommendation: Replace the min:max range with an explicit multiport rule listing only the four defined ports:

const portList = Object.values(API_PROXY_PORTS).join(',');
await execa('iptables', [
  '-t', 'filter', '-A', CHAIN_NAME,
  '-p', 'tcp', '-d', apiProxyIp,
  '-m', 'multiport', '--dports', portList,
  '-j', 'ACCEPT',
]);

---

F2 — HIGH: Dangerous Port List Divergence Between Squid and iptables

Files: src/squid-config.ts:14-31, containers/agent/setup-iptables.sh:DANGEROUS_PORTS

Evidence:

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}
# Ports blocked in Squid but NOT in agent iptables:
missing = {5984, 6984, 8086, 8088, 9200, 9300}
# CouchDB (5984/6984), InfluxDB (8086/8088), Elasticsearch (9200/9300)

Issue: Six database/time-series ports are blocked in the Squid config's "deny" ACL but are not listed in setup-iptables.sh's DANGEROUS_PORTS array. Since the agent's OUTPUT filter chain drops all TCP not explicitly allowed, this is currently mitigated by the default-deny rule — connections to these ports would still be blocked.

However, if any of these ports were reachable via DNAT redirect through Squid (which would normally allow HTTP/HTTPS ports), they could be accessed. More importantly, if Squid's http_access deny dangerous_ports ACL is the only enforcement, it is subject to future Squid misconfig. The single source-of-truth principle is violated: the two lists MUST stay in sync.

Recommendation: Define DANGEROUS_PORTS in one place (e.g., src/types.ts) and generate both the Squid ACL config and setup-iptables.sh from it, or at minimum add a CI test that asserts both lists are identical.

---

F3 — MEDIUM: mount, unshare, setns in Seccomp ALLOW + AppArmor Unconfined

Files: containers/agent/seccomp-profile.json, src/docker-manager.ts:1083-1099

Evidence:

# Parsed from containers/agent/seccomp-profile.json
# defaultAction: SCMP_ACT_ERRNO
# ALLOWED syscalls include: mount, unshare, setns, clone, clone3

// src/docker-manager.ts:1099
security_opt: [
  'no-new-privileges:true',
  `seccomp=\$\{config.workDir}/seccomp-profile.json`,
  'apparmor:unconfined',  // ← AppArmor disabled
],

Analysis:

• mount is allowed by seccomp and needed for entrypoint.sh's procfs mount. SYS_ADMIN is dropped via capsh before user code runs, which should prevent successful mount calls from user code. However, user-namespace-based mounts (unshare -m) on Linux kernels with kernel.unprivileged_userns_clone=1 (common on Ubuntu) do not require SYS_ADMIN.
• unshare (allowed by seccomp) + clone with CLONE_NEWUSER can create user namespaces as an unprivileged user, which can then be used to mount bind mounts within the new namespace. This is a known container escape vector when combined with setns.
• apparmor:unconfined removes the AppArmor policy which would normally block these operations independently.
• no-new-privileges:true prevents privilege escalation via setuid binaries, but does not block user namespaces.

Recommendation: Add unshare and setns to the seccomp ERRNO list. Alternatively, consider re-enabling AppArmor with a custom profile that allows only the needed mount operations during container startup (before capsh), then restricts it after.

{
  "action": "SCMP_ACT_ERRNO",
  "names": ["unshare", "setns"]
}

---

F4 — MEDIUM: 5-Second Token Unset Race Window

File: containers/agent/entrypoint.sh:644-660, 691-707

Evidence:

# Both chroot and non-chroot paths have identical pattern:
  chroot /host /bin/bash -c "... exec capsh ... exec \$\{SCRIPT_FILE}" &
  AGENT_PID=$!

  # Wait for agent to initialize and cache tokens (5 seconds)
  sleep 5

  # Unset all sensitive tokens from parent shell environment
  unset_sensitive_tokens

  # Wait for agent command to complete and capture its exit code
  wait $AGENT_PID

Issue: For 5 seconds after the agent process starts, all sensitive tokens (GITHUB_TOKEN, ANTHROPIC_API_KEY, OPENAI_API_KEY, etc.) remain visible in /proc/[PARENT_PID]/environ and /proc/[AGENT_PID]/environ. A malicious subprocess spawned immediately at agent startup could read these before unset_sensitive_tokens executes.

The one-shot-token.so LD_PRELOAD library partially mitigates this by intercepting getenv() calls, but:

1. The library uses XOR-only obfuscation (key=0x5A) — not cryptographic
2. Native code that reads /proc/self/environ directly (bypassing getenv) is not protected
3. The 5-second sleep is a heuristic, not a synchronization primitive

Recommendation: Instead of a fixed-time sleep, use a pipe/socket-based synchronization where the agent signals back to the parent shell when tokens have been cached (reading them exactly once), then the parent unsets them. This eliminates the race entirely.

---

F5 — MEDIUM: IPv6 Bypass if Sysctl Disable Fails Silently

Files: src/host-iptables.ts:66-78, containers/agent/setup-iptables.sh:16-28

Evidence:

// src/host-iptables.ts
async function disableIpv6ViaSysctl(): Promise(void) {
  try {
    await execa('sysctl', ['-w', 'net.ipv6.conf.all.disable_ipv6=1']);
    await execa('sysctl', ['-w', 'net.ipv6.conf.default.disable_ipv6=1']);
    ipv6DisabledViaSysctl = true;
    logger.info('IPv6 disabled via sysctl (ip6tables unavailable)');
  } catch (error) {
    logger.warn('Failed to disable IPv6 via sysctl:', error);  // ← logs warning, continues
  }
}

# containers/agent/setup-iptables.sh
sysctl -w net.ipv6.conf.all.disable_ipv6=1 2>/dev/null || echo "[iptables] WARNING: ..."
sysctl -w net.ipv6.conf.default.disable_ipv6=1 2>/dev/null || echo "[iptables] WARNING: ..."
# ← execution continues regardless

Issue: If ip6tables is unavailable AND sysctl fails to disable IPv6 (e.g., in environments where the sysctl is not writable), IPv6 traffic from the agent container is completely unfiltered. An agent tool that uses IPv6 (or resolves a hostname to an IPv6 address) would bypass all L7 filtering.

Recommendation: Make failure to restrict IPv6 a hard error:

if ! sysctl -w net.ipv6.conf.all.disable_ipv6=1 2>/dev/null; then
  echo "[iptables] FATAL: Cannot disable IPv6 and ip6tables unavailable. Cannot guarantee network isolation." >&2
  exit 1
fi

---

F6 — LOW: DLP Scanning Bypassed via HTTPS (Without SSL Bump)

Files: src/dlp.ts, src/squid-config.ts:134-176

Evidence:

// src/squid-config.ts — DLP uses url_regex
const urlAccessLines = config.urlPatterns
  .map((pattern, i) => `acl allowed_url_\$\{i} url_regex \$\{pattern}`)
// url_regex only sees full URL for HTTP; for HTTPS only CONNECT hostname is visible

Issue: DLP patterns (detecting GitHub PATs, Anthropic keys, OpenAI keys in URLs) only apply to HTTP traffic. For HTTPS (CONNECT method), Squid only sees the CONNECT hostname:443 line — the full URL with any embedded tokens is invisible without SSL Bump. An agent that exfiltrates credentials via HTTPS URL query parameters would bypass DLP scanning.

Recommendation: Document this limitation clearly in docs/ and recommend --enable-ssl-bump for deployments where DLP coverage of HTTPS is required. Alternatively, note that DLP's primary value is for HTTP APIs (e.g., package registries on port 80).

---

📋 Evidence Collection Summary

Command	Purpose
cat src/host-iptables.ts	Network egress filtering rules
cat containers/agent/setup-iptables.sh	Agent-side NAT rules
cat src/squid-config.ts | grep DANGEROUS_PORTS -A 30	Squid dangerous ports ACL
cat containers/agent/seccomp-profile.json | python3 -c "..."	Seccomp profile analysis
cat src/docker-manager.ts | grep cap_add -A 10	Container capabilities
cat src/domain-patterns.ts	Domain validation logic
npm audit --json | python3 -c "..."	Dependency vulnerabilities
cat containers/agent/entrypoint.sh	Token lifecycle and privilege drop
python3 -c "ports = ...	Port range gap computation

---

✅ Recommendations

🔴 High — Fix promptly

1. [F1] Fix API proxy iptables port range — Replace \$\{minPort}:\$\{maxPort} with an explicit multiport --dports rule in src/host-iptables.ts:371. This closes the port 10003 gap with a one-line change.

2. [F2] Synchronize dangerous port lists — Add CouchDB (5984/6984), InfluxDB (8086/8088), Elasticsearch (9200/9300) to setup-iptables.sh's DANGEROUS_PORTS array. Consider a unit test asserting parity between the two lists.

🟠 Medium — Address in next sprint

3. [F3] Restrict unshare/setns in seccomp — Add both to the SCMP_ACT_ERRNO list in containers/agent/seccomp-profile.json. These are not needed for any documented functionality and create user-namespace escape opportunities.

4. [F4] Replace 5-second sleep with synchronization primitive — Use a pipe or signal file to synchronize token-unset with agent token caching, rather than relying on a fixed sleep 5.

5. [F5] Fail hard when IPv6 cannot be restricted — Treat sysctl failure + ip6tables unavailability as a fatal error to prevent unfiltered IPv6 egress.

🟡 Low — Document or track for future work

6. [F6] Document DLP's HTTPS limitation — Add a note to docs/ that DLP scanning requires --enable-ssl-bump for full HTTPS coverage.

---

📈 Security Metrics

Metric	Value
Source files analyzed	8 (host-iptables.ts, setup-iptables.sh, squid-config.ts, domain-patterns.ts, docker-manager.ts, entrypoint.sh, seccomp-profile.json, server.js)
npm dependency vulnerabilities	0 Critical, 0 High, 0 Moderate
STRIDE threats identified	6
Attack surfaces enumerated	Network egress (L3/L4/L7), container filesystem, credential environment, API proxy sidecar
Critical findings	0
High findings	2
Medium findings	3
Low findings	1

AI generated by Daily Security Review and Threat Modeling

• expires on Apr 1, 2026, 1:59 PM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-04-01T13:59:34.103Z.

Closed by Workflow