Hardening Inter-Process Communication
In this lesson, you will learn how to use Mandatory Access Control (MAC) systems like SELinux or AppArmor to explicitly restrict how different services talk to each other, preventing low-privilege processes from exploiting high-privilege ones.
The Problem with Default Permissions
By default, standard Linux permissions (like User/Group/Other) are often too permissive for Inter-Process Communication (IPC). If a low-privilege web server and a high-privilege system manager both have access to the same shared memory segment or Unix domain socket, a compromise of the web server could allow an attacker to send malicious commands to the manager.
Implementing MAC for IPC
Mandatory Access Control allows us to define a "policy" that acts as a gatekeeper. Unlike standard permissions, which depend on who is running the process, MAC systems look at the security context of the process itself. Even if a process has root privileges, the MAC policy can forbid it from interacting with another specific process.
For example, using an AppArmor profile, you can restrict a service's ability to communicate over specific sockets:
# Example snippet of an AppArmor profile for a web service
profile web-service /usr/bin/web-service {
# Deny all unix socket communication except to the logging daemon
deny unix,
allow unix peer=(label=logging-daemon),
}
By explicitly defining that web-service can only "talk" to logging-daemon, you create an isolated path. Even if the web service is exploited, the attacker cannot reach out to other high-privilege services on the system, because the kernel’s MAC subsystem will drop any IPC attempts that violate the policy.
Why this works
This approach implements the principle of Least Privilege at the kernel level. By limiting communication paths, you ensure that even if one component of your system is breached, the attacker remains trapped within the narrow "sandbox" defined by the security policy. You are essentially shifting security from a "trusted user" model to a "validated process path" model.
Key Takeaway: Use Mandatory Access Control to define strictly allowed communication channels between processes, effectively siloing high-privilege services from lower-privilege entry points.