I am looking at enabling debugging in some of our production containers. In our usecase, I would not need CAP_SYS_PTRACE. yama.ptrace_scope on my system is set to the default 1 (“restricted ptrace”, debug children only). I have a recent version of the Linux kernel (4.20), so am not susceptible to the classic seccomp ptrace hole that existed in the 2.x and early 3 branches. Further, user namespaces are in use to map my container UIDs to a high range on the host.
Given these things I thought it could be okay to enable the ptrace syscall in the seccomp profile our containers use. However, looking at the Docker seccomp profile page, I see a callout for why ptrace is disabled:
ptrace: Tracing/profiling syscall, which could leak a lot of information on the host. Already blocked by dropping CAP_PTRACE.
So I am wondering, under what conditions should it be safe to allow the ptrace syscall in a Docker container today? Is it ever safe?