IPC, RPC, D-Bus, COM and Local Trust Boundaries — DedSec Project

Local communication is still a network of trust decisions. Learn how processes expose services, identify callers, marshal data and accidentally create privilege boundaries that are weaker than they look.

Learning objectives

By the end of this module you should be able to:

• Explain IPC threat modeling and identify its most important trust boundary, state transition, and evidence source.
• Explain Unix sockets and peer credentials and identify its most important trust boundary, state transition, and evidence source.
• Explain D-Bus names, policies and activation and identify its most important trust boundary, state transition, and evidence source.
• Explain Windows COM/RPC identity and impersonation concepts and identify its most important trust boundary, state transition, and evidence source.
• Explain named pipes and local endpoints and identify its most important trust boundary, state transition, and evidence source.
• Explain message marshalling and schema validation and identify its most important trust boundary, state transition, and evidence source.

Deep concepts

1. IPC threat modeling

Inter-process communication crosses a privilege boundary whenever one process can ask another to perform work. Identify caller identity, server privilege, object/operation, message schema, and the exact point where authorization is enforced.

2. Unix sockets and peer credentials

Unix-domain sockets can expose filesystem permissions and kernel-provided peer identity such as UID/GID. Applications should use authenticated peer context from the transport where available rather than trusting a caller-supplied username inside the message.

3. D-Bus names, policies and activation

D-Bus combines bus names, method calls, policy, and service activation. Review which peers can own or call sensitive names, how activation changes privilege/state, and whether method-level authorization remains correct after policy or package changes.

4. Windows COM/RPC identity and impersonation concepts

Windows COM/RPC can carry caller security context into privileged services. Security depends on authentication level, endpoint permissions, impersonation behavior, and whether the server authorizes the original caller before performing a privileged operation.

5. named pipes and local endpoints

Named pipes and similar local endpoints are not automatically trusted because they are local. Restrict who can connect or create the endpoint, authenticate the peer, bound message sizes, and prevent untrusted clients from influencing privileged file or process operations.

6. marshalling and schema validation

IPC data is untrusted input even when it comes from another local process. Use explicit schemas, bounded lengths, versioning, canonical encodings, and reject unknown or contradictory fields at the component that owns the decision.

7. capability-style handles

A narrow, unforgeable handle can represent authority more safely than a global name plus a broad service account. Capability-oriented designs should minimize ambient privilege and ensure handles cannot be confused across users, tenants, or resource types.

8. brokered architectures and least privilege

A broker allows a sandboxed or low-privilege client to request a small set of privileged operations. The broker must treat every request as hostile, validate caller context and parameters, and expose the minimum operation surface needed by the client.

Authorized lab sequence

• Lab 1 — Inventory local IPC endpoints on a disposable Linux VM or Termux environment using read-only tools.

• Lab 2 — Design a toy privileged broker API and write an explicit authorization matrix for each operation.

• Lab 3 — Trace a local client/server exchange and identify where caller identity is established, transformed and checked.

Knowledge checks

Answer these without looking at the notes:

Next modules

Recommended related modules: 021, 041, 062, 073, 074, 119. From the main menu, choose Search lessons to find related sections across the full guide.