[apparmor] How extensively does AppArmor lock down Docker containers?

[John Johansen]

On 10/23/2016 04:26 PM, Sam Ghods wrote:
> We are evaluating moving from CentOS/SELinux/Docker to Ubuntu/AppArmor/Docker and had a question regarding AppArmor.
> 
> Docker's SELinux policy specifically uses Multi Category Security (MCS) to enforce that each individual container on a system can only access the files on the host labeled for that specific container (more details: article <https://opensource.com/business/14/9/security-for-docker>, presentation <https://www.youtube.com/watch?v=a9lE9Urr6AQ>). That is, if two Docker containers A and B are spun up on a single host, the default SELinux security policy that comes with Docker will actually enforce that in the event of a breakout, the linux process in container A will not be able to access the files belonging to container B. Not only that, but the only way files can be mounted into a container from the host is if the volumes are suffixed with ":Z", thus telling Docker to make sure to add the relevant MCS labels to the files on the host in that path so that the container can access them.
> 
> On the contrary, I cannot find any references to a similar mechanism in AppArmor. Instead, Docker's default AppArmor profile <https://docs.docker.com/engine/security/apparmor/> seems to primarily be about denying access to specific filesystem paths and host resources, not about denying access between containers.
> 
> My question is, if we use Docker's default AppArmor profile, will we get the same effective protection as using SELinux as described above? Will AppArmor block access from one container to another container's files? If yes, how does it accomplish it?
> 

I am unfamiliar with what Docker is doing with AppArmor so take the following with a large grain of salt.

>From the default profile and very limited looking I would say no, Docker's use of apparmor is not protection one container from another.

There are a few ways to achieve this in apparmor, libvirt and lxc use per container generated profiles so that paths can be rewritten and each container/domain gets its own unique profile.

Another approach that could be used would be policy namespaces and variables to provide something more akin (but definitely not MCS) to the MCS that selinux is doing. In this approach you have a single base profile and load it to a unique policy namespace for each container. The variables need to be set to the correct paths on a per container basis.

However, when it comes to mount namespaces apparmor's protections are currently very limited and constrained, and the protection for cross container ns confinement is limited at best. There is on going work to address this but until new hooks can be landed in the kernel it does not really have the ability to properly mediate cross mount namespace paths satisfactorily.