Resolving PTRACE_ATTACH Restriction Issues in Docker Containers

In the past two years, we have been using Docker extensively both for developing and executing systems in a production environment, and all current products for our customers are developed specifically for this containerization system. It is worth noting that Docker changes quite strongly from version to version, adding both additional features (Swarm, Compose) and additional tools for enhancing the security and control of applications.

So with great surprise, we recently discovered that a container that was developed and tested some time ago does not work in the current version of Docker. The fact is that the container was not quite typical and the strace utility was used inside it to analyze the process behavior. We previously wrote in detail about this application of the utility on Habrahabr.

Today, our developers finally got their hands on the implementation of this problem
container to the application and they find that it no longer works. Having begun to understand the reason for this behavior, we saw that strace, specifically ptrace, cannot join processes and gives an error of the form:

strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf 

The case is quite rare, and the solution is not easily identified by the collective mind of the developers, although there are quite a lot of different clues. So what was the matter?

Seccomp subsystem

In new Linux kernels, the new Docker uses the seccomp kernel function, which allows you to block system calls inside the container. The Docker documentation for this feature is here . Ptrace is among the blocked system calls. The mechanism is --security-opt seccomp=/path/to/file.json using the Docker run --security-opt seccomp=/path/to/file.json , which allows you to specify a file that describes what is allowed and what is not. Since our container works in a protected environment, we disable this feature completely: --security-opt seccomp=unconfined .

Ptrace behavior

Strace gave us a hint that there is a certain pseudo-file /proc/sys/kernel/yama/ptrace_scope , which also describes the limitations of ptrace. We look into the kernel documentation and find out that everything is not as simple as it was before. Values ​​of 0-3 in this pseudo file significantly change the behavior of ptrace:

• 0 - the UID of the tracing process must match the UID of the traced process or be 0 (the behavior as it was before);
• 1 - limited ptrace, processes must be related, the traced process must be descendant
  the tracing or tracing process must have a UID = 0;
• 2 - for the tracing process, the CAP_SYS_PTRACE flag must be set or the child sets the PTRACE_TRACEME flag for itself;
• 3 - tracing is prohibited.

By completing

 docker exec -it <container> cat /proc/sys/kernel/yama/ptrace_scope 

we found that the file is set to 1, respectively, not being a related process, strace could not connect to the process being traced. At the same time, an attempt to set the value 0 to / proc / sys / kernel / yama / ptrace_scope was unsuccessful, a message was received that "/ proc is read only".

Privileged Container Launch

The Docker flag helped us to overcome this limitation, allowing privileged execution: --privileged , and in the application initialization we added setting the value "0" to the / proc / sys / kernel / yama / ptrace_scope pseudo file.

 echo 0 > /proc/sys/kernel/yama/ptrace_scope 

As a result, the problem was successfully solved. An example of the solution and arguments for running the container can be found in our GitHub repository for web ssh proxy .

It was interesting to note that the Linux kernel receives significant security enhancements and additional tools for managing security settings, which are difficult to learn about if you don’t keep a hand on the pulse and work within applications that develop over long life cycles in stable environments. One fine day you discover a new amazing world of improvements that “suddenly” showed themselves thanks to such an annoying occasion.