Restrict ptrace to descendant processes

Description

The Yama security module adds the kernel.yama.ptrace_scope sysctl, which restricts the ptrace system call used by debuggers to inspect and modify other processes:

• 0: a process can trace any process with the same user ID.
• 1: a process can only trace its own descendants, unless the target allows it explicitly.
• 2: only processes with the CAP_SYS_PTRACE capability can use ptrace.
• 3: nobody can use ptrace, and the value cannot be changed until the next reboot.

Rationale

With the default 0, malware running as a user can attach to the user's SSH agent, password manager or browser and read keys and session tokens from their memory. Limiting ptrace to descendants keeps normal debugging (gdb ./program, strace command) working while blocking attachment to unrelated running processes.

Impact

With 1, attaching a debugger to an already running process (gdb -p, strace -p) needs root or CAP_SYS_PTRACE. With 2, every use of ptrace needs privileges, which breaks debugging by regular users. 3 cannot be undone without a reboot.

Setting

Parameters

The value used is your override (tailoring file), else the profile's, else the one of the profile it extends, else the default. Bounds limit what an override may set.

Audit

Run sysctl kernel.yama.ptrace_scope. The value must be at least {{ ptrace_scope }}. Then check that no sysctl configuration file sets a lower value.

Automated: every check must pass. Scanners report each check by its id.

running

Running value of kernel.yama.ptrace_scope.

key: kernel.yama.ptrace_scope
operator: '>='
value: '{{ ptrace_scope }}'

Remediation

Create /etc/sysctl.d/60-cirsec.conf containing kernel.yama.ptrace_scope = {{ ptrace_scope }}, remove any other assignment of this key, then run sysctl --system.

Rollback

Remove the line from /etc/sysctl.d/60-cirsec.conf and run sysctl -w kernel.yama.ptrace_scope=0. A value of 3 can only be lowered by rebooting after removing the line.

set

Generated from check running: the engine writes the fix for every output, it sets the expected value and the check runs again after.

Each release turns these fixes into remediate.sh and an Ansible role per profile: dry run by default, a fix runs only when its check fails.

References

• Linux kernel documentation - Yama The Linux Kernel Organization, vendor-doc, accessed 2026-10-18
• ANSSI-BP-028 v2.0 - Recommandations de configuration d'un système GNU/Linux (R11) ANSSI, guide, accessed 2026-10-18

Mappings

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

People and lifecycle