ipc-namespace.md (6300B)
1 --- 2 title: "IPC Namespace" 3 section: "Linux" 4 sectionSlug: "linux-hardening" 5 sourcePath: "src/linux-hardening/containers-namespaces/container-security/protections/namespaces/ipc-namespace.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/linux-hardening/containers-namespaces/container-security/protections/namespaces/ipc-namespace.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # IPC Namespace 14 15 ## Overview 16 17 The IPC namespace isolates **System V IPC objects** and **POSIX message queues**. That includes shared memory segments, semaphores, and message queues that would otherwise be visible across unrelated processes on the host. In practical terms, this prevents a container from casually attaching to IPC objects belonging to other workloads or the host. <sup>[[1]](#references)</sup> 18 19 Compared with mount, PID, or user namespaces, the IPC namespace is often discussed less often, but that should not be confused with irrelevance. Shared memory and related IPC mechanisms can contain highly useful state. If the host IPC namespace is exposed, the workload may gain visibility into inter-process coordination objects or data that was never intended to cross the container boundary. 20 21 ## Operation 22 23 When the runtime creates a fresh IPC namespace, the process gets its own isolated set of IPC identifiers. This means commands such as `ipcs` show only the objects available in that namespace. If the container instead joins the host IPC namespace, those objects become part of a shared global view. POSIX shared-memory objects are exposed through a `tmpfs` normally mounted at `/dev/shm`. <sup>[[1]](#references)</sup> <sup>[[2]](#references)</sup> 24 25 This matters especially in environments where applications or services use shared memory heavily. Even when the container cannot directly break out through IPC alone, the namespace may leak information or enable cross-process interference that materially helps a later attack. 26 27 ## Lab 28 29 You can create a private IPC namespace with: 30 31 ```bash 32 sudo unshare --ipc --fork bash 33 ipcs 34 ``` 35 36 And compare runtime behavior with: 37 38 ```bash 39 docker run --rm debian:stable-slim ipcs 40 docker run --rm --ipc=host debian:stable-slim ipcs 41 ``` 42 43 ## Runtime Usage 44 45 Docker and Podman isolate IPC by default. Kubernetes typically gives the Pod its own IPC namespace, shared by containers in the same Pod but not by default with the host. Host IPC sharing is possible through `hostIPC`, but it should be treated as a meaningful reduction in isolation rather than a minor runtime option. <sup>[[3]](#references)</sup> 46 47 ## Misconfigurations 48 49 The obvious mistake is `--ipc=host` or `hostIPC: true`. This may be done for compatibility with legacy software or for convenience, but it changes the trust model substantially. Another recurring issue is simply overlooking IPC because it feels less dramatic than host PID or host networking. In reality, if the workload handles browsers, databases, scientific workloads, or other software that makes heavy use of shared memory, the IPC surface can be very relevant. 50 51 ## Abuse 52 53 When host IPC is shared, an attacker may inspect or interfere with shared memory objects, gain new insight into host or neighboring workload behavior, or combine the information learned there with process visibility and ptrace-style capabilities. IPC sharing is often a supporting weakness rather than the full breakout path, but supporting weaknesses matter because they shorten and stabilize real attack chains. 54 55 The first useful step is to enumerate what IPC objects are visible at all: 56 57 ```bash 58 readlink /proc/self/ns/ipc 59 ipcs -a 60 ls -la /dev/shm 2>/dev/null | head -n 50 61 ``` 62 63 If the host IPC namespace is shared, large shared-memory segments or interesting object owners can reveal application behavior immediately: 64 65 ```bash 66 ipcs -m -p 67 ipcs -q -p 68 ``` 69 70 In some environments, `/dev/shm` contents themselves leak filenames, artifacts, or tokens worth checking: 71 72 ```bash 73 find /dev/shm -maxdepth 2 -type f 2>/dev/null -ls | head -n 50 74 strings /dev/shm/* 2>/dev/null | head -n 50 75 ``` 76 77 IPC sharing rarely gives instant host root by itself, but it can expose data and coordination channels that make later process attacks far easier. 78 79 ### Full Example: `/dev/shm` Secret Recovery 80 81 The most realistic full abuse case is data theft rather than direct escape. If host IPC or a broad shared-memory layout is exposed, sensitive artifacts can sometimes be recovered directly: 82 83 ```bash 84 find /dev/shm -maxdepth 2 -type f 2>/dev/null -print 85 strings /dev/shm/* 2>/dev/null | grep -Ei 'token|secret|password|jwt|key' 86 ``` 87 88 Impact: 89 90 - extraction of secrets or session material left in shared memory 91 - insight into the applications currently active on the host 92 - better targeting for later PID-namespace or ptrace-based attacks 93 94 IPC sharing is therefore better understood as an **attack amplifier** than as a standalone host-escape primitive. 95 96 ## Checks 97 98 These commands are meant to answer whether the workload has a private IPC view, whether meaningful shared-memory or message objects are visible, and whether `/dev/shm` itself exposes useful artifacts. 99 100 ```bash 101 readlink /proc/self/ns/ipc # Namespace identifier for IPC 102 ipcs -a # Visible SysV IPC objects 103 mount | grep shm # Shared-memory mounts, especially /dev/shm 104 ``` 105 106 What is interesting here: 107 108 - If `ipcs -a` reveals objects owned by unexpected users or services, the namespace may not be as isolated as expected. 109 - Large or unusual shared memory segments are often worth following up on. 110 - A broad `/dev/shm` mount is not automatically a bug, but in some environments it leaks filenames, artifacts, and transient secrets. 111 112 IPC rarely receives as much attention as the bigger namespace types, but in environments that use it heavily, sharing it with the host is very much a security decision. 113 114 ## References 115 116 - [1] [`ipc_namespaces(7)` - Linux manual page](https://man7.org/linux/man-pages/man7/ipc_namespaces.7.html) 117 - [2] [`shm_overview(7)` - Linux manual page](https://man7.org/linux/man-pages/man7/shm_overview.7.html) 118 - [3] [Kubernetes API Reference - PodSpec `hostIPC`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)