Solutions for various problems (e.g., here and here) suggest enabling SYS_PTRACE when running a container that, say, needs to run a debugger or a fuzzer. Given that the capability isn't enabled by default, there must be some security implications of granting it -- the official documentation gives a vague "could leak a lot of information on the host". Presumably this means it could allow information about the host to be leaked to the runtime environment of the container -- but what information? Are there any other security implications?
There's some good detail on this topic, in this whitepaper.
Essentially the problem is that allowing ptrace will allow the contained process to bypass any seccomp filter in place, allowing dangerous syscalls to be made. To quote the document
CAP_SYS_PTRACE: The ability to useptrace(2)and recently introduced cross memory
attach syscalls such as process_vm_readv(2)andprocess_vm_writev(2).
If this capability is granted and the ptrace(2) syscall itself is not blocked by a seccomp
filter(as discussed more in Section 8.3 on page74),
this will allow an attacker to bypass other seccomp restrictions.
Update - As mentioned below in comments from @forest the above only applies to versions of the kernel before 4.8, so modern Linuxes (possibly excepting RHEL/CENTOS 7 and earlier which are still around) shouldn't have this problem.