Unlisted hostname request terminates policy boundary instead of returning a clean denial

The issue is in the network policy enforcement layer of the sandbox runtime. Start by examining the boundary and supervisor code that handles DNS resolution and connection attempts for hostnames not listed in the policy. Look for the audit event generation and error handling paths. The reproduction steps provide a concrete test case; run the sandbox with the given policy and trace the failure. 'Done' means the request is denied with a clean error (like EACCES), a DENIED audit event is emitted, and the sandbox remains Ready.

This was generated by AI during triage.

Summary

A network request to a hostname that is completely absent from the sandbox policy can terminate the policy boundary instead of returning a normal deny result. The OpenShell exec client then loses its relay before receiving the command's exit status, and the sandbox transitions out of Ready.

The equivalent negative test against an allowed hostname on a disallowed port fails cleanly with EACCES, emits a DENIED audit event, and leaves the sandbox Ready.

Environment

• Kubernetes on Linux/amd64
• RuntimeClass: kata-qemu
• Kata Containers: 4.2.0
• OpenShell development builds, including the sandbox-runtime change from PR #3574

The gateway and supervisor used mutable development tags and may have been from different builds. Version skew is a plausible contributing factor and should be checked during triage.

Policy

version: 1

filesystem_policy:
  include_workdir: true
  read_only: [/usr, /lib, /proc, /dev/urandom, /app, /etc, /var/log]
  read_write: [/sandbox, /tmp, /dev/null]

landlock:
  compatibility: best_effort

network_policies:
  example_http:
    name: example-http
    endpoints:
      - host: example.com
        port: 80
        protocol: tcp
    binaries:
      - { path: "/**" }

Reproduction

1. Create a sandbox with the policy above and wait until policy version 1 is loaded.

2. Confirm the allowed request succeeds:

   bash -c 'exec 3<>/dev/tcp/example.com/80; printf "GET / HTTP/1.0\r\nHost: example.com\r\nConnection: close\r\n\r\n" >&3; IFS= read -r line <&3; printf "%s\n" "$line"'
   

   Observed: HTTP/1.1 200 OK.

3. Attempt a request to a hostname absent from the policy:

   bash -c 'exec 3<>/dev/tcp/example.org/80'
   

Actual behavior

The exec client reports:

The service is currently unavailable: exec relay closed before the command reported an exit status

The supervisor reports a mediated-DNS failure followed by loss of its boundary channel:

mediated DNS accept failed; retrying
boundary terminated: boundary lost during wait: transport error

The supervisor terminates and the sandbox transitions from Ready to Stopped/DependenciesNotReady.

Expected behavior

• The request to example.org:80 is denied normally.
• The caller receives a deterministic nonzero result such as EACCES.
• A DENIED audit event records the destination and denial reason.
• The policy boundary, supervisor, and sandbox remain healthy and Ready.

Control case

With the same policy, connecting to the allowed hostname on an unauthorized port behaves correctly:

/usr/bin/bash: connect: Permission denied

Audit output:

OCSF NET:OPEN [MED] DENIED /usr/bin/bash(0) -> 198.18.0.0:81 [reason:transparent_tcp_mapping_denied]

The sandbox remains Ready afterward.

Suggested validation

• Add an end-to-end test for DNS resolution/connection to a hostname absent from all network policy endpoints.
• Assert that the request is denied and audited without terminating the boundary or supervisor.
• Run the test with matching component builds and, separately, with a supported mixed-version configuration if version skew is expected to work.