Bugzilla – Bug 1128245
Please enable YAMA LSM
Last modified: 2024-06-25 13:52:05 UTC
CONFIG_SECURITY_YAMA has been requested already on the relevant mailing list: https://lists.opensuse.org/opensuse-kernel/2019-02/msg00032.html But I have been asked to open a bug report, so here we go. Yama, the Linux Security Module, adds a new ptrace_scope sysctl knob to control restrictions for ptrace and everything else that requires PTRACE_MODE_ATTACH: https://www.kernel.org/doc/Documentation/security/Yama.txt It enforces (some would argue: it creates) isolation between sibling processes, which is generally desirable from a security perspective. In the highest setting, even privileged processes are prevented from tracing others. Unprivileged processes can already declare themselves not dumpable in order to achieve the same effect. But reality is sometimes sobering, and not all processes that should be not dumpable also make use of this mechanism. One prominent example is gnupg-agent, which is not dumpable and in principle vulnerable to siblings attaching and extracting secrets from its memory. gnupg is aware of this issue and refused to set PR_SET_DUMPABLE on the grounds it can be circumvented. This is certainly not wrong, yet ptrace remains one attack vector that *can* be avoided, and as far as I know Debian has made the decision to patch gnupg-agent as a consequence. Other projects occasionally overlook ptrace & friends when they conceive security mechanisms. I am aware of at least one example, and can present the case in this thread once the project has released a fix. Also not every project is receiving as much attention as say gnupg-agent. I don't necessarily argue to enable ptrace_scope by default, as Ubuntu is doing. But it can be useful in some scenarios, and it would be nice to give users a choice. Only for reference: This has been proposed already in 2014 on the mailing list, but did not receive a reply: https://lists.opensuse.org/opensuse-kernel/2014-09/msg00015.html Best Regards Ed
I should add that AppArmor and SELinux allow ptrace mediation as well. However, AppArmor requires knowledge which processes need to be restricted, and second requires a profile to be written. This is error prone and potentially cumbersome. Using ptrace_scope in comparison is dead simple, it is just a sysctl knob. SELinux could almost replace Yama, but unfortunately there is no granularity. deny_ptrace is like setting ptrace_scope to the highest level.
Putting some more relevant people to Cc. I find it'd be OK to enable the security module, it would be just an additional layer.
It adds these hooks: LSM_HOOK_INIT(ptrace_access_check, yama_ptrace_access_check), LSM_HOOK_INIT(ptrace_traceme, yama_ptrace_traceme), LSM_HOOK_INIT(task_prctl, yama_task_prctl), LSM_HOOK_INIT(task_free, yama_task_free), And I don't see any hot path in there. In anyway, the current default is YAMA_SCOPE_RELATIONAL. I am switching off yama by default via sysctl. This should be done by a new CONFIG_ option IMO -- will try to push it upstream.
(In reply to Jiri Slaby from comment #3) > In anyway, the current default is YAMA_SCOPE_RELATIONAL. I am switching off > yama by default via sysctl. This should be done by a new CONFIG_ option IMO > -- will try to push it upstream. Or not, the security modules have to be enabled via command line like security=yama, so yama is disabled by default.
Pushed to master/for-next.
Thank you.