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