Unix Domain Socket

Expanded Definition

A Unix Domain Socket is a local inter-process communication channel on a single host. In security tooling, it is often used where one process needs to deliver events, commands, or telemetry to another without exposing a network service or traversing TCP/IP. That local-only boundary is the key distinction: it changes the trust model, but it does not make the exchange automatically safe.

In the Falco and gVisor Sentry pattern described here, the socket carries syscall messages from the sandboxed runtime into Falco for inspection. That is a practical integration choice, not a protocol for remote access. The common misunderstanding is to treat “not on the network” as equivalent to “low risk.” Local IPC still depends on correct file permissions, process isolation, and host hardening. When those assumptions are weak, the socket becomes part of the security boundary rather than merely plumbing.

For broader context on how local trust boundaries can still be abused, the ENISA Threat Landscape is a useful authority on the wider threat environment.

Examples and Use Cases

Unix Domain Sockets appear wherever two host-local components need low-latency, permissioned communication.

• Falco receives syscall telemetry from a gVisor Sentry over a local socket so detection stays inside the host boundary.
• Container runtimes and security agents use sockets to exchange status, policy, or event streams without opening a listening network port.
• System services use sockets for control interfaces when the operator expects local administrative access only.
• Logging or monitoring daemons use socket-based ingestion to reduce network exposure and simplify local access control.

The tradeoff is clear: a Unix Domain Socket reduces network attack surface, but it concentrates trust in the host. If the host is multi-tenant, over-permissive, or poorly segmented, the local channel can become easier to abuse than a well-protected network service.

Security Implications

Misunderstanding a Unix Domain Socket often leads teams to under-protect it because it is “local.” That can expose telemetry, command channels, or privileged control paths to processes that should not have them. The result is usually not remote exploitation, but local privilege abuse, interception, spoofing, or denial of service through file-system permissions, namespace confusion, or process compromise.

In a sandboxing or observability design, the socket can also widen blast radius if the consumer assumes messages are inherently trustworthy. A compromised workload that can reach the socket may be able to inject misleading events, suppress useful signals, or trigger fragile parsing paths in the listener. The observable symptom is often not a crash first, but inconsistent security data, unexpected connection failures, or gaps in telemetry that make incident triage harder.

Practitioner observation: when a socket becomes the only path between a sandbox and a detector, access control and lifecycle management matter as much as the code that reads the messages.

Domain and Governance Relevance

Unix Domain Sockets matter in security operations because they often carry the control or telemetry plane between components running on the same host. That makes ownership, filesystem permissions, service account boundaries, and host isolation part of the security design, not just deployment detail. In practice, the governance question is who can create the socket, who can connect to it, and what trust is assumed once the connection exists.

For NHI-adjacent environments, the relevance is strongest when the socket links an autonomous runtime, sandbox, or security agent to a local collector. The socket itself is not an identity system, but it can transport signals that influence policy decisions about non-human workloads. If that channel is weakly governed, security tooling may act on untrusted data from the very systems it is meant to observe.

That is why Unix Domain Socket design should be reviewed alongside host hardening and local trust boundaries, not treated as a neutral implementation detail.

Related resources from NHI Mgmt Group

• Why do cross-domain attacks create more risk than single-domain intrusions?
• How should security teams build a cross-domain identity programme?
• How should security teams harden domain controllers that still need legacy authentication support?
• Why do domain controllers with NTLMv1 enabled increase domain compromise risk?