7

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?

4

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.

| improve this answer | |
  • 2
    Rory, this is no longer correct as of kernel 4.8. Linux has changed the order of the seccomp filter application in the syscall path and ptrace can no longer be used to bypass seccomp. The docs may be outdated. That doesn't mean that ptrace isn't a horrible API with a huge attack surface, of course... – forest Dec 24 '19 at 5:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.