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

Enforcing Ptrace Restrictions

Use profiles to block ptrace-based memory inspection by unauthorized debugging tools.

In this lesson, you will learn how to use AppArmor profiles to prevent unauthorized debugging tools from inspecting the memory of sensitive processes via ptrace.

Understanding Ptrace Risks

The ptrace system call allows one process to observe and control the execution of another. While essential for legitimate development tools like gdb or strace, it is a significant security risk. If a malicious actor gains access to a low-privilege user account, they could use ptrace to attach to a running root-level process or a sensitive service (like a database or password manager) to dump its memory and extract credentials or encryption keys.

Restricting Access with AppArmor

AppArmor provides a simple, path-based mechanism to enforce restrictions on ptrace. By default, processes might be allowed to trace others based on system-wide settings, but you can explicitly tighten this behavior within an application's profile using the ptrace rule.

To restrict which processes a specific application can trace, or to deny tracing entirely, you add the following directive to your AppArmor profile:

profile sensitive-app /usr/bin/sensitive-app {
  # Deny all ptrace attempts by this process
  deny ptrace,

  # Alternatively, restrict ptrace to specific scopes (e.g., only same-profile)
  ptrace peer=sensitive-app,
  
  # Standard profile rules continue here...
  /usr/bin/sensitive-app r,
}

By adding deny ptrace, you ensure that even if sensitive-app is compromised, the attacker cannot leverage it to inject code into or read the memory of other processes on the system. If you want to be more surgical, using ptrace peer=... allows you to define a "sandbox" where a process can only perform debugging operations on its own children or peers, effectively walling off critical system services from being targeted by external debuggers.

This defense-in-depth approach is vital for hardening services that handle secrets. By restricting the ptrace capability, you shrink the attack surface significantly, ensuring that memory inspection tools cannot be weaponized against your hardened services.

Key Takeaway: Use the deny ptrace or ptrace peer= rules within your AppArmor profiles to restrict memory inspection capabilities and prevent unauthorized processes from compromising sensitive application state.