This document describes the sandboxing and threat model for the JUD:GE worker.

• Submissions are untrusted code.
• The worker must prevent data exfiltration, host compromise, and abuse of resources.

The worker uses Docker with the following default protections:

• User-defined bridge network (jud-ge-bridge) for isolation
• no-new-privileges security option
• CapDrop=ALL
• Read-only root filesystem (configurable)
• /tmp as tmpfs (size-limited)
• /output bind-mounted as the only writable host path
• CPU/Memory/PIDs limits enforced in container config

Requirements:

• The worker must reach the submission server via HTTP
• External egress should be blocked

Current implementation:

• Containers run on a user-defined bridge network.
• Ports are published to the host to allow the worker to call http://127.0.0.1:.
• DNS is disabled by setting the container resolver to 0.0.0.0.

Limitations:

• DNS blocking does not prevent raw IP egress.

Recommended hardening:

1. Create an iptables/nftables rule that drops outbound traffic from the bridge subnet.
2. Allow only host -> container traffic and container -> itself.

Example (Linux, iptables):

# Identify docker bridge subnet for jud-ge-bridge, then:
iptables -A FORWARD -s <JUDGE_SUBNET> ! -d <HOST_IP> -j DROP

• The worker extracts ZIP entries with path normalization.
• Absolute paths and .. traversal are rejected.

• Model artifacts are removed immediately after scoring.
• Metadata and logs are retained.

• File outputs must be relative to /output.
• Absolute paths and .. traversal are rejected.

• Run worker on dedicated hosts whenever possible.
• Use separate Docker daemon or rootless mode for additional isolation.
• Keep Redis and Postgres on private networks.