AppArmor Unix Socket Rules Need Both Sides
Learn how to properly write AppArmor security policies for Unix domain sockets covering both client and server sides with peer label testing.
Stock photo for illustration only, not from the actual event
- Unix domain sockets are common control channels for local services.
- A profile allowing only one side of a conversation is incomplete.
- Sockets include filesystem-based, abstract, and anonymous types.
- Testing requires real peer labels and audit log reviews.
Unix domain sockets serve as a frequent control channel for local services, often bypassing network inspection, relying on filesystem permissions, or using abstract names that do not appear as files. While AppArmor can mediate these connections with fine-grained Unix socket rules, a profile that allows just one side of a conversation does not constitute a complete security policy.
The AppArmor apparmor.d(5) documentation outlines the mediation of filesystem-based, abstract, and anonymous Unix domain sockets. These rules distinguish socket addresses, peer labels, and operations. On systems featuring fine-grained mediation, older coarse network rules map into equivalent socket rules, assisting local service isolation provided policies are tested against actual peer identities.
Stock photo for illustration only, not from the actual event
Filesystem sockets possess a distinct path, whereas abstract sockets hold an address within the abstract namespace without a persistent directory entry. Although a profile can match address patterns, an address alone does not guarantee that a peer is trusted. The peer's AppArmor label functions as an independent signal that policies should factor in when supported by the platform.
Understanding the architecture of Unix domain sockets and process relationships on Linux is crucial because these local communication channels are frequently overlooked compared to external TCP/IP networks. Constraining them with AppArmor helps close potential security gaps where compromised applications might otherwise reach privileged backend services.
Documentation highlights that pattern matching follows file-path rules in ways that can surprise policy authors. A wildcard matching one directory level may fail to match an internal slash. Abstract names maintain their own representations, meaning administrators should never copy a filesystem-path pattern directly into an abstract-socket rule assuming identical semantics.
When a service listens on a socket, protection must cover both listen and connect paths. Clients might gain connection permissions while servers accept connections from any peer, potentially allowing compromised clients to reach unintended privileged services.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment