Course contentsShow
← Linux
Lesson 973 of 1,8199. Security Hardening and Mandatory Access ControlFree lesson

Setting Limits on Signal Sending

Limit the ability of processes to send signals to other tasks, preventing process termination attacks.

In this lesson, you will learn how to restrict the ability of processes to send signals to one another, a critical defense against termination-based denial-of-service attacks.

Why Limit Signals?

In a standard Linux environment, any process running with the same UID as another can send signals (like SIGKILL or SIGTERM) to terminate that process. If an attacker compromises a low-privilege service, they could use that service to maliciously kill other critical processes running under the same user account. To harden our system, we use AppArmor to define strict boundaries on which processes can signal others.

Implementing Signal Restrictions

While we have previously looked at path-based and capability restrictions, AppArmor also allows us to define signal rules within our profiles. By default, processes are often allowed broad permissions. By explicitly defining signal access, we follow the principle of least privilege.

Consider a scenario where we have a sensitive web service that should never need to terminate other system processes. We can add a rule to its AppArmor profile to restrict signal sending:

profile web-service /usr/bin/web-service {
  # Allow receiving signals for standard operations
  allow signal (receive) peer=unconfined,

  # Deny all signal sending by default, 
  # or explicitly allow only what is necessary:
  deny signal (send) peer=*,
  
  # If the service must be able to signal a child, list it specifically:
  signal (send) peer=/usr/bin/worker-process,
}

By using deny signal (send) peer=*, we prevent this process from sending signals to any other process on the system, regardless of UID. If a process attempts to send a SIGKILL to a target not listed in our profile, the kernel will block the request and generate an audit log entry (which you can debug using the audit tools discussed in previous lessons).

This technique effectively neuters common attack vectors where a compromised service attempts to destabilize the system by "shooting" other tasks. Even if the service is compromised, it lacks the architectural "permission" to interfere with the rest of the OS.

Key Takeaway: Restricting signal sending via AppArmor profiles prevents malicious or compromised processes from terminating system tasks, providing a vital layer of defense against process-based sabotage.