Files
2026-09-15 15:24:03 -04:00

96 lines
3.7 KiB
Bash
Executable File

#!/bin/sh
# =====================================================================
# Network namespace guard for owuitools-vmagent.
#
# WHY A SECOND GUARD AND NOT THE EXISTING ONE
#
# owuitools-netguard already exists and already does this for the api
# container. The agent is not put behind it because their allowlists are
# different in a way that matters: the agent needs Ollama, and Ollama has
# no authentication and serves DELETE /api/delete. Adding it to the api
# container's allowlist would mean a URL-validation bug in fetch_page
# could delete the model the whole assistant runs on.
#
# So the agent gets its own namespace with a strictly smaller allowlist:
# owuitools-vmgw, and nothing else. vmgw is the one that may talk to
# Ollama and to Open WebUI, and it exposes exactly three paths.
#
# The agent's other channel - vmd - is a unix socket on a bind mount, so
# it does not appear here at all. That is the point of using a socket:
# a filesystem permission cannot be reached by a network bug.
#
# The result is a hard allowlist of ONE address and ONE port.
# =====================================================================
set -eu
# What this applied, kept with every other component's log. `exec` so the
# redirection covers the verification output at the end too, which is the
# part worth having: it is the difference between "the filter ran" and
# "the filter is in force".
LOG_DIR="${OWUITOOLS_LOG_DIR:-/logs}"
if [ -d "$LOG_DIR" ] && [ -w "$LOG_DIR" ]; then
exec > >(tee -a "$LOG_DIR/vmguard.log") 2>&1
fi
# From docker-compose.yml, for the reason in netguard/firewall.sh: the
# address is pinned there, and a second copy here is the one that gets
# forgotten. It must stay equal to OWUITOOLS_VMGW_URL on the vmagent
# container - that is the address the agent dials, and this is the only
# address it is allowed to reach.
GW_IP="${OWUITOOLS_VMGW_IP:-172.22.2.10}" # the only permitted destination
GW_PORT="${OWUITOOLS_VMGW_PORT:-8000}"
echo "Configuring owuitools vmguard..."
# Fail closed before opening anything.
iptables -w 10 -P INPUT DROP
iptables -w 10 -P OUTPUT DROP
iptables -w 10 -P FORWARD DROP
# Filter table only. Docker's embedded DNS resolver installs NAT rules in
# this namespace; flushing nat would break name resolution.
iptables -w 10 -F INPUT
iptables -w 10 -F OUTPUT
iptables -w 10 -F FORWARD
# Loopback: the embedded resolver at 127.0.0.11 and the agent's own
# healthcheck.
iptables -w 10 -A INPUT -i lo -j ACCEPT
iptables -w 10 -A OUTPUT -o lo -j ACCEPT
iptables -w 10 -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -w 10 -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# The whole allowlist.
iptables -w 10 -A OUTPUT -d "$GW_IP/32" -p tcp --dport "$GW_PORT" \
-m conntrack --ctstate NEW -j ACCEPT
# Nothing may start a conversation with the agent. It claims work from a
# shared volume and answers there; it serves nothing.
# Verify the rules that matter actually took, and that the policies are
# still DROP. A firewall that silently failed to apply is worse than
# none, because everything downstream carries on as though it were
# enforced - the same assertion netguard/firewall.sh makes.
iptables -w 10 -C OUTPUT -d "$GW_IP/32" -p tcp --dport "$GW_PORT" \
-m conntrack --ctstate NEW -j ACCEPT
test "$(iptables -S INPUT | head -n 1)" = "-P INPUT DROP"
test "$(iptables -S OUTPUT | head -n 1)" = "-P OUTPUT DROP"
test "$(iptables -S FORWARD | head -n 1)" = "-P FORWARD DROP"
touch /tmp/firewall-ready
echo
echo "owuitools vmguard ready."
echo " outbound $GW_IP:$GW_PORT (vmgw) and nothing else"
echo " inbound nothing"
echo " the host, the LAN, Ollama and Open WebUI are NOT reachable directly"
echo
trap 'exit 0' TERM INT
while :; do
sleep 3600 &
wait $!
done