Tracing processes securely

In a nutshell, process tracing is a mechanism for one process (which we call a tracer) to have complete control over another process: a tracee. With great power comes great responsibility, and ptrace can vastly affect security if implemented improperly.

In a nutshell, you don’t want ptrace to be a mechanism to reveal more information than the user invoking it could normally see. Intuitively, this means an ordinary user should be able to trace its own processes; root should be able to trace everything. This is in fact very close description of the default algorithm the kernel uses for ptrace access mode checks when no special Linux Security Modules (LSM) are loaded. In fact, privileged access is enabled if the calling process has CAP_SYS_PTRACE capability. By the way, this means that the creator of a process namespace such as gVisor’s runsc is automatically granted this privilege. Then, undumpable processes refuse PTRACE_ATTACH. This is also expected as you typically make a process undumpable to prevent third parties from peeking into it.

A scenario where the scheme above fails. If an attacker breaks into a user process, it could use ptrace to read SSH agent memory and steal private keys. This is possible even if a compromised process is properly sandboxed and can’t access ~/.ssh directly.

The Yama LSM takes care of it. It can be configured so that tracing is possible only from a parent to a child, or if the tracee explicitly requested it. ptrace(2) man page has all the details.