yama.ptrace_scope是限制ptrace的核心手段，因其作为Yama LSM唯一可调参数，以0-3整数分级精准控制“谁可attach谁”，无需重启、不依赖其他模块，改写即生效。
为什么改 yama.ptrace_scope 是限制 ptrace 的核心手段
Linux 内核从 2.6.18 起引入 Yama LSM（Linux Security Module），把 ptrace 权限控制从“全有或全无”变成可配置的分级策略。yama.ptrace_scope 就是这个模块里唯一影响 ptrace 行为的开关，它不依赖 SELinux/AppArmor，也不需要重启内核，改完立刻生效。它的值不是布尔量，而是整数等级，每个值对应一种隔离强度——不是“开/关”，而是“谁可以 attach 谁”。
yama.ptrace_scope 各取值的实际效果与适用场景
不同发行版默认值不同（Ubuntu/Debian/Fedora 多为 1），但含义一致：
-
0：完全放开。任何进程可 ptrace 同用户下的任意进程。调试方便，但等同于关闭防护，生产环境禁用 -
1：默认推荐值。只允许父进程 ptrace 子进程（即 fork 出来的子进程），或拥有 CAP_SYS_PTRACE 权限的进程。覆盖绝大多数合法调试需求，同时阻断跨用户、跨会话的 strace/gdb 注入 -
2：严格模式。只有 root 或显式授予权限的进程才能 ptrace 其他进程。能防住非特权用户的调试行为，但 VSCode/PyCharm 等 IDE 的 Python 调试器会直接失败（除非手动给 Python 解释器加 cap） -
3：彻底禁用。所有非 root 进程调用 ptrace 都返回 -EPERM。连strace -p $PID都会报 “Operation not permitted”，适合高安全要求的审计/隔离环境
怎么安全地设置并持久化 yama.ptrace_scope
临时修改只影响当前启动周期，重启即失效；持久化需写入 sysctl 配置。两者都需 root 权限：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 临时生效（验证用）：
echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope - 持久化（推荐）：在
/etc/sysctl.d/10-yama.conf中写入kernel.yama.ptrace_scope = 1，再执行sudo sysctl --system - 验证是否生效：
cat /proc/sys/kernel/yama/ptrace_scope输出应为设定值 - 注意：某些容器或 WSL2 环境中，宿主机设置对容器内进程无效，必须在容器内单独配置
设成 1 后哪些工具会受影响？怎么绕过？
设为 1 后，以下行为会被拒绝：
-
strace -p $OTHER_USER_PID（非子进程、非 root）→ 报错 “Operation not permitted” - VSCode Python 调试器静默退出（因 debugpy fork 子进程后无法 ptrace 它）
- GDB attach 到非子进程时卡住或失败
应对方式不是降级到 0，而是按需授权：
- 给特定二进制加能力：
sudo setcap cap_sys_ptrace+ep $(which python3)（适用于本地开发） - 换 attach 模式：让 debugpy 先作为父进程监听，VSCode 再连接，规避子进程限制
- 容器中运行时加
--cap-add=SYS_PTRACE，而非改全局ptrace_scope
真正容易被忽略的是：设为 2 或 3 后，ps、top 不受影响，但 /proc/$PID/status 里的 TracerPid 字段会始终为 0——这不是 bug，是 Yama 主动隐藏跟踪关系，意味着你无法靠读 proc 文件判断是否已被 ptrace。
