AppArmor Unix Socket Mediation Requires Rules on Both Client and Server

An AppArmor profile that permits only one end of a Unix domain socket conversation is an incomplete policy. That is the central point of a dev.to write-up on Unix socket mediation, which lays out how AppArmor governs local socket traffic, why both the client and server sides need rules, and how to confirm the policy actually enforces what was intended.

What AppArmor mediates

Unix domain sockets are a standard control channel between local services. According to the post, they frequently escape network inspection, depend on filesystem permissions, or use abstract names that never appear as files on disk. The apparmor.d(5) documentation it cites describes mediation for filesystem-based, abstract and anonymous Unix sockets. Rules can distinguish the socket address, the label of the peer, and the operation, and on systems with fine-grained mediation the older coarse network rule translates into the equivalent socket rule.

Both endpoints need rules

The asymmetry is the trap. A client profile may be scoped tightly enough for a connect operation, while the listening service is simultaneously allowed to accept connections from any peer. In that configuration, a compromised client can reach a more privileged service the policy never meant to expose. The write-up advises protecting both the listen path and the connect path, and remembering that helper processes and short-lived children inherit the same label, so they fall under the same rules as the parent.

Addresses and labels are separate signals

A filesystem socket has a path; an abstract socket has an address in the abstract namespace and no persistent directory entry. Matching on the address alone does not prove the peer is trusted, the post argues, because the peer's AppArmor label is an independent control, and both should be considered where the platform supports it. Pattern matching also follows file-path conventions in ways that can surprise authors: a wildcard that appears to cover one directory level may not match a slash inside the address, and abstract names use their own representation. The article warns against copying a filesystem-path pattern into an abstract-socket rule and assuming the meaning carries over.

Fail-closed behavior can look like a bug

The documentation notes that mediation can fail closed when memory allocation fails. The post argues this is the right default but produces ambiguous operational symptoms: a service may see ENOMEM or a denied connection during a resource spike. Logs should identify the profile and the specific rule that denied the operation, without dumping message contents or credentials.

Testing needs distinct peer labels

A common testing mistake is creating a socket as root and connecting as the same user. That proves nothing when both processes share one profile, because the intended peer-label rule is never exercised. The recommended procedure is to run the client under its own profile, attempt the connection, and capture the audit result, then review the server's accept path and the client's connect path independently. The write-up also stresses that a profile loading successfully is not proof it enforces the intended rule; operators should check the loaded profile, the kernel feature set, and the audit log, and record the test result alongside the service version and host image.

A review checklist

The post suggests starting with an inventory of local control channels: the socket path or abstract name, the listener process and its profile, the expected client processes and their labels, the operations each client needs, the credentials carried over the socket, and the relevant filesystem permissions and mount views. Broad rules that let any peer reach a privileged operation should then be removed. Where a service has multiple clients, the privileged endpoint and the management endpoint should be separated, or an application-level authorization check added, since AppArmor can constrain the peer but the server still has to validate the request.

Where the profile stops

Unix socket mediation does not protect data once a trusted process has received it. An allowed client can still send a malicious payload, and an allowed server can still expose files through its own business logic. The profile also does not replace filesystem permissions, service authentication, or least-privilege process identities.

Why it matters

Local sockets often sit between a service's management plane and everything else on a host, and they typically bypass the network controls organisations rely on elsewhere. Making that conversation explicit, with a given label allowed to connect to a given address and the server accepting only from that label, converts implicit local trust into a policy that can be audited and regression-tested. The both-endpoints rule is what separates a profile that looks restrictive from one that actually contains a compromised client.