Priority
P1 - High
Summary
AWF relies on userspace iptables rules that can be modified or flushed by any process with CAP_NET_ADMIN. The agent container has this capability for setup-iptables.sh, which means malicious code running inside could disable the firewall.
Current Behavior
The agent container is started with NET_ADMIN capability:
// src/docker-manager.ts:305-310
cap_add: ['NET_ADMIN'],
This is required for setup-iptables.sh to configure NAT rules:
# containers/agent/setup-iptables.sh
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 172.30.0.10:3128
iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination 172.30.0.10:3128
Attack Vector
Malicious code can flush all NAT rules:
# Inside agent container - completely disables firewall redirect
iptables -t nat -F OUTPUT
# Now traffic goes direct instead of through Squid
curl https://evil.com # Bypasses Squid (but host iptables may still block)
Current Mitigation
Host-level iptables provides a backup layer, but:
- Host rules only apply to
awf-net bridge traffic
- They don't re-inspect at L7 (domain level)
- They're a last resort, not primary defense
Impact
- Firewall bypass: Malicious code can disable traffic redirection
- Defense in depth weakened: Relies on host iptables as backup
- Attack surface: Any process with CAP_NET_ADMIN can manipulate rules
Proposed Solutions
Option A: Drop NET_ADMIN after setup (Recommended)
- Run
setup-iptables.sh as privileged init container
- Drop
NET_ADMIN before running user command
- Use Docker's
--cap-drop after initialization
// Start with NET_ADMIN, run setup, then drop it
cap_add: ['NET_ADMIN'],
// After setup-iptables.sh completes:
// docker exec awf-agent capsh --drop=cap_net_admin -- <user-command>
Option B: Use network namespaces differently
- Set up iptables in a separate init container
- Share network namespace with agent container (without NET_ADMIN)
Option C: Seccomp to block iptables syscalls
Add seccomp profile blocking setsockopt with IPT_SO_SET_* options after setup.
Files to Modify
src/docker-manager.ts:305-310 - Capability management
containers/agent/entrypoint.sh - Drop capabilities after setup
- New:
containers/agent/seccomp.json - Syscall restrictions
Code Locations
containers/agent/setup-iptables.sh - NAT rule setup
src/docker-manager.ts:307 - NET_ADMIN capability grant
Related
- Host iptables provides backup via
src/host-iptables.ts
Priority
P1 - High
Summary
AWF relies on userspace iptables rules that can be modified or flushed by any process with
CAP_NET_ADMIN. The agent container has this capability forsetup-iptables.sh, which means malicious code running inside could disable the firewall.Current Behavior
The agent container is started with
NET_ADMINcapability:This is required for
setup-iptables.shto configure NAT rules:# containers/agent/setup-iptables.sh iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 172.30.0.10:3128 iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination 172.30.0.10:3128Attack Vector
Malicious code can flush all NAT rules:
Current Mitigation
Host-level iptables provides a backup layer, but:
awf-netbridge trafficImpact
Proposed Solutions
Option A: Drop NET_ADMIN after setup (Recommended)
setup-iptables.shas privileged init containerNET_ADMINbefore running user command--cap-dropafter initializationOption B: Use network namespaces differently
Option C: Seccomp to block iptables syscalls
Add seccomp profile blocking
setsockoptwithIPT_SO_SET_*options after setup.Files to Modify
src/docker-manager.ts:305-310- Capability managementcontainers/agent/entrypoint.sh- Drop capabilities after setupcontainers/agent/seccomp.json- Syscall restrictionsCode Locations
containers/agent/setup-iptables.sh- NAT rule setupsrc/docker-manager.ts:307- NET_ADMIN capability grantRelated
src/host-iptables.ts