The field of maliciously accessing another process's memory has been broadly studied in the Linux environment.

But for some reason I am not able to find similar discussion/similarities for the Docker environment, even despite the fact that Covert Channel Attacks have been studied.

Differences I can think of are:

  1. PID namespace - what is the impact of it?
  2. reduced capabilities and systemcall filtering can make it harder for a simple container execution (docker run --it ubuntu:latest /bin/bash) to access the memory

I wish to ask what are the similarities and difference between the two environments? Suppose all capabilities are granted is there really a different whether I run a container or not?

2 Answers 2


Memory doesn't belong to a container, it belongs to a process. By default a container will setup a namespace for PIDs (and other things) so a process running under a container will only see processes running under that same container and therefore only be able to read the memory of those process. However, if all capabilities were granted then the process could escape that container's PID namespace and potentially access all processes.

Is there a difference between whether you run in a container or not? Yes, to the extent that a process makes use of the capabilities it has.


It's possibly important to note, that Docker Linux containers (using runc) are just Linux processes with some restrictions applied to them.

If you strip away the isolation layers and increase their privileges, they'll act a lot like any other privileged process on the host.

Specifically if you're running the contained process as root and then you add all capabilities, that's going to make it a lot easier for the contained process to read the memory of other processes as (apart from the AppArmor/SELinux profile and seccomp filter) the contained process is effectively root at that point.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .