AppArmor AF_UNIX mediation is the control of Unix domain socket connections through AppArmor policy. It allows administrators to permit or deny socket communication based on labels, socket type, address, and peer context, closing an important gap in workload and process isolation on Linux.
Expanded Definition
AppArmor AF_UNIX mediation is a Linux confinement capability that extends AppArmor policy beyond file and process actions into Unix domain socket communication. In practical terms, it lets a security team decide whether one confined workload may connect to another local service, send data over a socket, or accept a peer connection based on labels, socket family, socket type, and peer context. This matters because many high-value interactions on Linux do not traverse the network stack at all. They happen locally through AF_UNIX sockets, often between tightly coupled services that share a host or container boundary.
Unlike broader network segmentation, AF_UNIX mediation is application-local and policy-driven. It is closely related to least privilege and inter-process isolation, and it complements access control thinking found in NIST SP 800-53 Rev 5 Security and Privacy Controls where control enforcement must be aligned to the actual communication path. Usage in the industry is still evolving because different Linux distributions, kernel versions, and AppArmor policy sets do not expose the same depth of mediation. The most common misapplication is assuming that network firewall rules protect local Unix socket traffic, which occurs when teams overlook host-resident service-to-service communication entirely.
Examples and Use Cases
Implementing AppArmor AF_UNIX mediation rigorously often introduces policy complexity, requiring organisations to weigh tighter workload isolation against additional tuning and troubleshooting overhead.
- A containerised database sidecar is allowed to talk to a local agent socket, while other processes on the host are denied, reducing the risk of lateral movement through shared IPC channels.
- A system service exposes an administration socket only to a signed management process, using peer labels to prevent untrusted helpers from issuing privileged commands.
- A desktop application is permitted to access a user session bus socket, but not a root-owned socket, limiting cross-context escalation opportunities.
- A security-sensitive workload is restricted from connecting to a backup agent’s Unix socket unless the peer context matches a predefined AppArmor label, supporting stronger service separation.
- Policy testing is aligned with Linux hardening guidance from the Linux kernel AppArmor documentation so that socket rules are validated against actual enforcement behaviour rather than assumed behaviour.
Why It Matters for Security Teams
Security teams often focus on TCP and UDP controls while missing the local attack surface created by AF_UNIX sockets. That gap matters because many privileged helpers, agents, and broker services communicate locally, and compromise of one confined process can become a path to another if socket mediation is weak or absent. AppArmor AF_UNIX mediation supports finer-grained containment, helping teams enforce boundaries between services that share the same kernel and host trust domain.
This is especially relevant in modern Linux estates where agents, orchestration components, and automation tooling are increasingly co-located with the workloads they manage. Local socket mediation can help reduce unintended control-plane exposure, but it only works when policy owners understand which processes need which peer relationships. For identity-aware systems, the same logic applies to local trust channels used by privileged automation or NHI-adjacent agents. Teams should validate rules, review peer labels, and check whether a denied socket connection would break a recovery path before production rollout. Additional operational guidance can be grounded in Linux security module documentation and mapped back to access-control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Organisations typically encounter the operational impact only after a service-to-service failure or containment incident, at which point AF_UNIX mediation becomes unavoidable to restore both function and isolation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions for local communications support least-privilege enforcement. |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement is the core control principle behind AF_UNIX mediation. |
Restrict local socket peers so only authorized processes can exchange data.
Related resources from NHI Mgmt Group
- When does agentless access control make more sense than proxy-based mediation?
- How should security teams choose between secrets management and access mediation?
- What is the difference between transport mediation and delegated trust in MCP?
- Who should own policy enforcement for API-to-event mediation?
