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

[github-actions[bot]]

Scope: AWF v0.23.1 — Full security review of network isolation, container hardening, credential protection, and domain filtering. 3,463 lines of security-critical code analyzed across 7 core files.
Previous escape-test results: Not available this run (git binary not in agent PATH prevented workflow log download).

---

📊 Executive Summary

The firewall demonstrates a strong, defense-in-depth security posture. The dual-layer network filtering (host DOCKER-USER chain + container OUTPUT chain), Squid L7 domain enforcement, and one-shot token protection represent well-implemented security controls. The dependency supply chain is healthy (npm audit reports 0 vulnerabilities).

Four issues of varying severity are documented below, none of which are immediately exploitable under default configuration.

Severity	Finding	Status
Medium	AppArmor unconfined during container init	Open
Medium	Squid port 3128 exposed to host	Open
Low	ICMP not blocked at container-level OUTPUT chain	Open
Low	one-shot token 5-second exposure window	Open
Info	XOR token-name obfuscation is trivially reversible	Open
Info	redactSecrets covers limited token formats	Open

---

🛡️ Architecture Security Analysis

Network Security Assessment ✅

Evidence gathered:

# Analyzed containers/agent/setup-iptables.sh and src/host-iptables.ts

Dual-layer filtering is correctly implemented:

1. Container-level (OUTPUT chain) — setup-iptables.sh:

   • DNAT TCP 80 → Squid:3128, TCP 443 → Squid:3128
   • Dangerous ports (22, 25, 3306, 5432, 6379, 27017, …) get RETURN (not redirected to Squid) then DROP
   • All remaining TCP: DROP
   • All UDP: DROP (blocks unauthorized DNS exfiltration)
   • DNS only to configured upstream servers (validated IP addresses)

2. Host-level (DOCKER-USER → FW_WRAPPER chain) — src/host-iptables.ts:

   • Squid source IP (172.30.0.10) gets ACCEPT (unrestricted outbound)
   • ESTABLISHED,RELATED ACCEPT
   • Localhost ACCEPT
   • DNS to configured upstreams ACCEPT
   • Squid TCP:3128 ACCEPT
   • Multicast (224.0.0.0/4), link-local (169.254.0.0/16) REJECT
   • UDP REJECT with logging
   • Final catch-all REJECT — covers ICMP and other protocols

3. IPv6: If ip6tables unavailable, IPv6 disabled via sysctl (net.ipv6.conf.all.disable_ipv6=1). ✅

4. DNS validation: parseDnsServers() enforces strict IPv4/IPv6 format before DNS servers are used in iptables rules. ✅

Finding: ICMP only blocked at host level (Low)
setup-iptables.sh drops TCP and UDP explicitly but does not explicitly drop ICMP in the container OUTPUT chain:

# setup-iptables.sh lines 405-407
iptables -A OUTPUT -p tcp -j DROP
iptables -A OUTPUT -p udp -j DROP
# ICMP not listed — passes through container OUTPUT to the host DOCKER-USER chain

ICMP is caught by the host FW_WRAPPER catch-all REJECT (step 8). However, if host-level rules are absent (e.g., race condition during startup, or partial setup failure), ICMP ping-tunneling to external IPs could leak data. Defense-in-depth would add an explicit ICMP DROP in the container chain.

---

Container Security Assessment

Evidence gathered:

# Analyzed src/docker-manager.ts lines 1100-1133, containers/agent/entrypoint.sh

Capabilities:

Capability	Agent Container	Init Container	Squid Container
NET_ADMIN	❌ Never	✅ (iptables setup)	❌
NET_RAW	❌ Dropped	N/A	❌ Dropped
SYS_CHROOT	✅ → dropped before user code	❌	❌
SYS_ADMIN	✅ → dropped before user code	❌	❌
SYS_PTRACE	❌ Dropped	❌	❌ Dropped
SYS_MODULE	❌ Dropped	❌	❌ Dropped

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

• defaultAction: SCMP_ACT_ERRNO — fail-closed (all unknown syscalls blocked)
• 343 explicitly ALLOWED syscalls (standard operations)
• 28 explicitly BLOCKED (ptrace, process_vm_readv/writev, kexec_*, init_module, reboot, umount, keyctl, etc.)

Resource limits (src/docker-manager.ts:1130-1133):

• mem_limit: 6g, pids_limit: 1000, cpu_shares: 1024

Finding: AppArmor unconfined during init (Medium)

// src/docker-manager.ts:1121-1124
security_opt: [
  'no-new-privileges:true',
  `seccomp=\$\{config.workDir}/seccomp-profile.json`,
  'apparmor:unconfined',  // ← Required for procfs mount, but broad
],

The agent container runs apparmor:unconfined to allow mount -t proc of a container-scoped procfs at /host/proc (needed for .NET CLR, JVM). While SYS_ADMIN is dropped via capsh before user code runs, the entrypoint.sh runs as root with SYS_ADMIN + apparmor:unconfined during the initialization window. Any vulnerability in the entrypoint logic (e.g., TOCTOU between procfs mount and capsh drop) could be leveraged in this window. A targeted AppArmor profile that allows only the mount operation needed would reduce this surface.

Positive: Docker socket is hidden by default:

// src/docker-manager.ts:893
agentVolumes.push('/dev/null:/host/var/run/docker.sock:ro');

Docker-in-Docker (--enable-dind) explicitly warns of firewall bypass risk.

---

Credential Protection Assessment ✅

one-shot token library (containers/agent/one-shot-token/one-shot-token.c):

• Intercepts getenv() via LD_PRELOAD
• On first read: caches value in process memory, calls unsetenv()
• Subsequent reads return the cached value — process works normally
• After 5 seconds: parent shell calls unset_sensitive_tokens to clear env

Finding: 5-second token exposure window (Low)

# containers/agent/entrypoint.sh:685-689
AGENT_PID=$!
sleep 5                        # ← 5-second window
unset_sensitive_tokens         # clears parent shell env

Any subprocess or /proc/1/environ read within the first 5 seconds retains access to all tokens. This window is intentional (to allow the agent process to initialize and cache tokens via LD_PRELOAD), but represents a race condition. Reducing the sleep or using a synchronization mechanism (e.g., the one-shot library signals readiness) could close this window.

API proxy credential isolation: When --enable-api-proxy is active, real API keys are excluded from agent environment (EXCLUDED_ENV_VARS set). The agent only sees placeholder tokens. ✅

Information: XOR obfuscation of token names is weak (Info)

// one-shot-token.c line: #define OBF_KEY 0x5A
// Token names XOR'd with 0x5A
static const unsigned char OBF_0[] = { 0x19, 0x15, 0x0a, 0x13, ... };

XOR with a static key is trivially reversed. The comment acknowledges this: "NOT cryptographic protection — a determined attacker can reverse the XOR." Acceptable for the stated goal (prevent strings discovery), but should not be relied on for any actual security guarantee.

---

Domain Validation Assessment ✅

Evidence gathered:

# Analyzed src/domain-patterns.ts in full

• Wildcard * converts to [a-zA-Z0-9.-]* (not .*) — prevents ReDoS catastrophic backtracking ✅
• Input length capped at 512 chars before regex matching ✅
• * and *.* explicitly rejected ✅
• Patterns with all-wildcard segments rejected (e.g., *.*.*) ✅
• Protocol-restricted matching ((domain.com/redacted) vs (domain.com/redacted)`) ✅
• Squid dstdomain adds a leading dot to match both exact domain and subdomains ✅

Finding: Squid port exposed to host (Medium)

// src/docker-manager.ts:377
ports: [`\$\{SQUID_PORT}:\$\{SQUID_PORT}`],  // 3128:3128 exposed on host
````
The Squid proxy port is published to the host's loopback. The Squid ACL includes:
````
acl localnet src 172.16.0.0/12
http_access allow localnet

Any process on the host (or any container on the bridge) can use (localhost/redacted) as a proxy and reach domains in the allowlist. The agent's domain ACL is enforced (so only allowed domains are reachable), but the network isolation is broader than intended: it's not restricted to only the agent container. This is partially intentional (needed for awf logs` commands) but could be exploited by a compromised sibling container or CI job step running alongside AWF.

---

Input Validation & Injection Assessment ✅

Shell metacharacters in agentCommand:

// src/docker-manager.ts:1148
command: ['/bin/bash', '-c', config.agentCommand.replace(/\$/g, '$$$$')],

The $$$$ escaping is for Docker Compose YAML variable interpolation only. The command is still interpreted by /bin/bash -c, so shell metacharacters in agentCommand (semicolons, backticks, $()) are executed as intended — this is the user's own shell command, not untrusted input, so this is by design and not a vulnerability.

DNS server injection: parseDnsServers() validates strict IPv4/IPv6 format — command injection via --dns-servers is not possible. ✅

---

⚠️ Threat Model (STRIDE)

Category	Threat	Evidence	Likelihood	Impact	Mitigation
Spoofing	Agent spoofs Squid traffic via raw socket	NET_RAW dropped; seccomp blocks raw socket creation	Low	High	Cap drop + seccomp ✅
Tampering	Modify iptables rules at runtime	NET_ADMIN never granted to agent; init container pattern	Very Low	Critical	Architecture ✅
Tampering	ICMP tunneling bypasses TCP/UDP filter	ICMP not blocked at container OUTPUT level	Low	Medium	Add container-level ICMP DROP
Repudiation	No forensic trail for ICMP traffic	ICMP not logged before host catch-all	Low	Low	Add LOG before REJECT for ICMP
Info Disclosure	Token leakage via /proc/1/environ	5-second window before unset	Low	High	Reduce sleep or add sync signal
Info Disclosure	Token leakage via DLP URL bypass	DLP opt-in; URL patterns in Squid	Medium	High	Enable --enable-dlp by default (opt-out)
Info Disclosure	Sibling host process uses exposed Squid	Port 3128 published to host	Low	Medium	Bind Squid only to container network
DoS	Resource exhaustion	pids_limit=1000, mem_limit=6g	Low	Medium	Limits in place ✅
Elevation of Priv	AppArmor unconfined + SYS_ADMIN during init	init window before capsh drop	Very Low	High	Targeted AppArmor profile
Elevation of Priv	DinD Docker socket escape	--enable-dind explicitly warned	Low (opt-in)	Critical	Warning present ✅

---

🎯 Attack Surface Map

Entry Point	File:Line	Protection	Risk
--allow-domains input	domain-patterns.ts:1	Validation + ReDoS guard	Low
--dns-servers input	cli.ts:828	IP format validation	Low
agentCommand shell	docker-manager.ts:1148	User-owned (not injection)	Info
Squid proxy port 3128	docker-manager.ts:377	Domain ACL enforced	Medium
Container procfs mount	entrypoint.sh:396	SYS_ADMIN dropped post-mount	Low
LD_PRELOAD token library	entrypoint.sh:709	getenv() intercept, 5s window	Low
--enable-dind flag	docker-manager.ts:882	Explicit warning only	Critical (opt-in)
AWF_DNS_SERVERS env var	setup-iptables.sh:129	Validated before use	Low
API proxy sidecar ports	host-iptables.ts:418	Port range allow via iptables	Low

---

✅ Recommendations

🔴 Medium Priority

1. Restrict Squid port binding to container network only

Change Squid port binding to avoid exposing it on the host loopback:

// src/docker-manager.ts:377 — current
ports: [`\$\{SQUID_PORT}:\$\{SQUID_PORT}`],

// Proposed: bind to 127.0.0.1 only (or remove port mapping entirely)
// ports: [`127.0.0.1:\$\{SQUID_PORT}:\$\{SQUID_PORT}`],

If awf logs commands need to reach Squid externally, document this requirement and scope the binding accordingly.

2. Create a targeted AppArmor profile for the agent container

Instead of apparmor:unconfined, write a minimal AppArmor profile that allows only the mount -t proc operation needed for /host/proc. This reduces the initialization attack surface while maintaining the functionality needed by .NET and JVM runtimes.

🟡 Low Priority

3. Add explicit ICMP DROP in container OUTPUT chain

In containers/agent/setup-iptables.sh, add an explicit ICMP drop with logging for audit visibility:

# Add before the final TCP/UDP DROP rules (after line ~393)
iptables -A OUTPUT -p icmp -m limit --limit 5/min \
  -j LOG --log-prefix "[FW_BLOCKED_ICMP] " --log-level 4 --log-uid
iptables -A OUTPUT -p icmp -j DROP

This provides container-level defense-in-depth and adds audit logging for ICMP-based exfiltration attempts.

4. Reduce or eliminate the one-shot token exposure window

The 5-second sleep before unset_sensitive_tokens creates a window where /proc/1/environ exposes all tokens. Options:

• Have the one-shot library write a signal file when it has cached all tokens, and wait for that signal instead of sleeping 5 seconds
• Reduce sleep to 1 second (or 0.5s) if the 5s was conservative

🟢 Informational

5. Consider making DLP opt-out instead of opt-in

The --enable-dlp flag enables URL scanning for credential patterns. Given the sensitive nature of AI agent workflows, enabling this by default (with --disable-dlp to turn off) would provide better default security for users who don't know about it.

6. Expand redactSecrets patterns

src/redact-secrets.ts covers Bearer tokens and common key patterns but misses some formats (e.g., AWS AKIA*, Slack xoxb-*). While this function is used for logging redaction (not enforcement), expanding it reduces accidental secret logging.

---

📋 Evidence Collection

Commands run during this review

# Security files analyzed:
wc -l src/host-iptables.ts containers/agent/setup-iptables.sh \
   src/squid-config.ts src/domain-patterns.ts containers/agent/entrypoint.sh \
   src/redact-secrets.ts containers/agent/one-shot-token/one-shot-token.c
# → 3,463 lines total

# Vulnerability audit:
npm audit --json | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['metadata']['vulnerabilities'])"
# → {'info': 0, 'low': 0, 'moderate': 0, 'high': 0, 'critical': 0, 'total': 0}

# Seccomp profile analysis:
python3 -c "import json; d=json.load(open('containers/agent/seccomp-profile.json')); ..."
# → defaultAction: SCMP_ACT_ERRNO, 343 ALLOW + 28 ERRNO rules

# Capability review:
grep -n "cap_drop\|cap_add" src/docker-manager.ts
# → SYS_CHROOT+SYS_ADMIN added (dropped before user code), NET_RAW+SYS_PTRACE+SYS_MODULE+MKNOD dropped

# Container OUTPUT chain:
grep -n "DROP\|REJECT\|DNAT" containers/agent/setup-iptables.sh
# → TCP DROP, UDP DROP, but no ICMP DROP

---

📈 Security Metrics

• Lines of security-critical code analyzed: 3,463
• Attack surfaces identified: 9
• STRIDE threat categories evaluated: 10
• npm vulnerabilities: 0 (critical: 0, high: 0)
• Seccomp blocked syscalls: 28 explicitly + all-others by default
• Dangerous ports blocked: 15 (both iptables + Squid ACL)
• Findings requiring action: 4 (0 critical, 2 medium, 2 low)

AI generated by Daily Security Review and Threat Modeling

• expires on Apr 2, 2026, 2:07 PM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-04-02T14:07:38.441Z.

Closed by Workflow