Clawk Gvisor Tap Vsock

Checked: 2026-07-14

Summary

Clawk’s gvisor-tap-vsock fork adds outbound-connection hooks to the upstream containers/gvisor-tap-vsock Go library. Clawk uses those hooks to check TCP, UDP, and ICMP destinations against its allowlist before the host opens the real connection.

The fork is a small network-policy seam, not a separate sandbox product. The Clawk virtual machine remains the workload isolation boundary.

Role in Clawk

• Guest networking: The upstream library provides a user-space virtual network, DHCP, DNS, and connection forwarding for VMs.
• Policy checkpoint: The fork lets Clawk run a callback immediately before each outbound host socket is opened.
• DNS context: A second callback reports DNS A-record answers so Clawk can associate a destination IP with the hostname the guest requested.
• Same policy on two hosts: Clawk’s documentation says its macOS and Linux providers enforce the same allowlist through this layer.
• Dependency pin: Clawk’s go.mod replaces upstream gvisor-tap-vsock with the fork at version v0.8.9-1.

The actual allowlist rules, policy layers, prompts, and denial records live in Clawk. This fork only supplies the hooks needed to enforce them.

Problem it solves

• Guest firewall control: A root user inside a VM could alter a firewall running inside that VM.
• Cross-platform filtering: macOS does not offer the same TAP and host-firewall workflow as Linux.
• Protocol gaps: Filtering only web requests would miss raw TCP, UDP, QUIC/HTTP-3, and ICMP traffic.
• Hostname visibility: Once DNS is resolved, a network connection normally contains an IP address rather than the original domain name.

The design acts like a door attendant outside the VM: the guest can request a connection, but the host-side proxy decides whether to open the outside door.

How it works

• User-space network: gvisor-tap-vsock runs gVisor’s Go network stack and presents the VM with a virtual gateway.
• Connection termination: Guest Ethernet traffic reaches the host daemon. The daemon terminates the guest-side flow and opens a new normal host socket to the destination.
• TCP hook: Before net.Dial("tcp", address), Clawk’s callback receives host:port. An error drops the flow.
• UDP hook: The same check runs before the UDP proxy dials its destination.
• ICMP hook: The callback receives the destination IP before the forwarder processes the echo packet.
• DNS observer: The embedded DNS server reports each IPv4 A answer as a hostname and IP pair.
• Optional API: New functional options—WithTCPFilter, WithUDPFilter, WithICMPFilter, and WithDNSObserver—keep default upstream behavior when no callback is supplied.
• Capacity change: The fork raises TCP forwarder requests in flight from 10 to 64 because an interactive policy decision can temporarily hold a slot.

Security boundary

• Outside the guest: Policy runs in the host process, so guest root cannot simply rewrite it.
• Before host dialing: Rejected flows are stopped before the proxy creates the external host connection.
• Protocols covered: The fork has explicit hooks for TCP, UDP, and ICMP.
• Fail behavior: The callback returns an error to reject a flow; a missing callback preserves upstream unrestricted forwarding.
• Trusted components: Clawk’s rule engine, DNS-to-IP tracking, the host daemon, the Go runtime, and the hypervisor-side transport are trusted.
• Not gVisor workload isolation: The project borrows gVisor’s network stack. It does not run the coding agent under gVisor’s system-call sandbox.
• Not a complete firewall: The patch exposes callbacks. Security depends on the consuming application installing correct callbacks for every virtual network.

Platforms

• Upstream transports: QEMU on Linux or macOS, vfkit, Hyper-V/vsock, Hyperkit, and User Mode Linux are documented upstream.
• Clawk macOS: Apple Virtualization.framework provides a file-handle network device, allowing the user-space proxy and filtering path without a packet firewall.
• Clawk Linux: Firecracker uses a TAP device. The OP said Clawk invokes sudo only to create/configure that device; filtering still happens in user space.
• Implementation: Pure Go library based on the gVisor TCP/IP stack.

Setup

As a Clawk user

• No separate install: The fork is compiled into Clawk through its Go module replacement.
• Manage rules in Clawk: Use clawk network allow, block, remove, list, and denials rather than configuring this library directly.

As a library consumer

1. Use the forked module: Pin the tagged fork or replace the upstream module.
2. Create callbacks: Implement destination checks for TCP, UDP, and ICMP plus an optional DNS observer.
3. Pass options: Supply the callbacks when creating the virtual network.
4. Fail closed: Ensure a missing, failed, or unready policy does not silently install nil callbacks.

The fork’s default branch is not the patched branch. The change is on egress-filters and tagged v0.8.9-1 and v0.8.9-0.

Network controls

• Default policy: Clawk documents allowlist-only egress. Connections to unlisted destinations are refused.
• Rule targets: Domains, wildcard domains, literal IPs, and CIDR ranges are supported.
• Rule scope: A Clawk grant covers every port and the TCP, UDP, and ICMP protocols for that destination.
• Built-ins: Common registries, language package services, GitHub, and model providers are pre-allowed by the default policy.
• Layering: Reusable policies, manifests, sandbox rules, blocklists, and live runtime grants can be combined with defined precedence.
• Visibility: Clawk records denied connections and uses observed DNS answers to show a hostname when possible.
• Inbound traffic: Upstream supports explicit host-to-guest port forwarding. This fork’s patch is focused on outbound checks.
• DNS: DNS resolution itself is allowed; the later connection is checked. The added observer currently reports IPv4 A answers.

Credentials

• No credential storage: The fork does not hold, inject, or broker secrets.
• Exfiltration control: Destination filtering limits where a compromised agent can send credentials or private data.
• Not sufficient alone: Data can still leave through any allowed destination, and a permitted service can be abused.
• Separate Clawk feature: Clawk’s credential handling is outside this fork and should be assessed independently.

Strengths

• Small patch: One commit adds 115 lines and removes 23 across forwarders, DNS, and virtual-network construction.
• Enforcement location: The decision occurs outside the guest and immediately before host dialing.
• Broad transport coverage: TCP and UDP include normal web traffic and QUIC; ICMP has its own hook.
• No host packet rules on macOS: Filtering does not depend on iptables, nftables, or a macOS packet firewall.
• Low coupling: Callback options avoid serializing application-specific policy into the upstream configuration format.
• Upstream foundation: It builds on the established Apache-2.0 containers/gvisor-tap-vsock project.

Limits

• Clawk-specific glue: The fork alone does not provide a usable allowlist interface or policy database.
• Nil means open: Consumers that omit callbacks receive upstream unrestricted behavior.
• Destination-wide grants: Clawk’s current rule model does not narrow an allowed hostname by port or protocol.
• Allowed-host risk: An agent can send arbitrary data to an allowed endpoint unless that service has its own controls.
• DNS limits: The observer patch explicitly handles A records; behavior for IPv6 AAAA answers needs verification.
• Host trust: A compromised host daemon or Clawk policy engine can bypass filtering.
• Maintenance drift: The patched tag is based on upstream v0.8.9, while the fork’s main branch is already behind later upstream commits.
• Sparse fork documentation: The fork README is the upstream README and does not explain the Clawk patch or safe integration steps.

Activity and maturity

As of 2026-07-14:

• Fork created: 2026-06-27.
• Patch: One unsigned commit, d84c3e5f, dated 2026-06-27.
• Tags: v0.8.9-1 and v0.8.9-0 point to the patched commit; GitHub shows no fork release object.
• Fork attention: 0 stars and 0 forks when checked; this is an internal Clawk dependency rather than a promoted standalone project.
• Upstream: containers/gvisor-tap-vsock began in 2020, had 413 stars and 96 forks, and released v0.8.9 on 2026-05-11.
• Clawk use: Clawk v0.2.0 pins the patched module, providing real integration evidence.
• Interpretation: The upstream network stack is established, but the security patch is new, compact, and not independently audited in the material checked.

Comparison context

Layer	Purpose
Clawk VM	Isolates the agent’s operating system, processes, and file system
gvisor-tap-vsock upstream	Gives the VM user-space networking, DNS, gateway, and forwarding
Clawk fork	Adds callback points before outbound connections and on DNS answers
Clawk policy engine	Decides which domains and addresses are allowed, records denials, and handles live rule changes

This separation matters: finding a gvisor dependency does not mean Clawk uses gVisor instead of a VM. It uses one gVisor component to police VM networking.

Hacker News context

• OP explanation: In comment 48893608, Clawk’s author said gvproxy terminates guest connections and re-dials them as host sockets, with the allowlist checked immediately before dialing.
• Root behavior: The same comment said macOS uses a file-handle NIC without a packet firewall, while Linux needs elevated access for Firecracker’s TAP device but retains the same user-space filter.
• Fork link: In comment 48894921, the OP linked this fork and described the change as a tiny hook in the TCP, UDP, and ICMP forwarders.
• Repository evidence: The patched branch also adds a DNS observer and raises the TCP in-flight limit.

Direct sources

• Clawk gvisor-tap-vsock fork
• Patched egress-filters branch
• Patch commit d84c3e5f
• Upstream gvisor-tap-vsock
• Clawk networking documentation
• Clawk module pin
• HN network explanation
• HN fork link
• Clawk HN discussion

Unknowns

• Audit: No independent security review of the fork or Clawk integration was found.
• IPv6 policy: DNS observation and end-to-end allowlist behavior for IPv6 were not established from the checked patch.
• Non-DNS destinations: Exact behavior for encrypted DNS, hard-coded IPs, aliases, and rapid DNS changes needs targeted testing.
• Failure modes: Public documentation does not fully state what happens if the live policy callback blocks, panics, or becomes unavailable.
• Upstreaming: No upstream pull request or plan to maintain the hooks against future upstream releases was found.
• Test coverage: The patch updates DNS call sites, but dedicated tests proving allow and deny behavior for every protocol were not visible in the commit diff.

Sources

• • imported AI research note for Clawk Gvisor Tap Vsock.