A seccomp call that has no root capabilities will make the call to the kernel.

Deprecation notice 1.

Overview 2. Building and Securing Containers 3.

Keeping Containers Fresh and Updateable 3.1.

Never Put Naked Pulls in FROM Instructions 3.2.

Using Docker Caching to Your Advantage 3.2.1.

Order Instructions to Take Advantage of Caching 3.2.2.

Deliberately Break Caching In Some Situations 3.3.

Ensuring the Provenance of Containers 3.4.

Leveraging Kubernetes and OpenShift to Ensure that Containers are Immutable 3.4.1.

Ways to Leverage Kubernetes and OpenShift 3.4.2.

Leveraging Kubernetes to Ensure that Containers Do Not Store Secrets or Sensitive Information 4.

Container Analysis Tools 4.1.

Atomic Command 5.

Locked-down, secure Firefox in a container 6.

Docker SELinux Security Policy 6.1.

MCS - Multi-Category Security 6.2.

Leveraging the Docker SELinux Security Model 7.

Container Security Practices 7.1.

Dropping Kernel Capabilities 7.2.

Dropping Root 7.3.

Exercise care in using the --privileged flag.

Content 7.5. tmpfile 7.6.

Do not bind the docker service to a TCP port 8.

Linux Capabilities and Seccomp 8.1.

Linux Capabilities 8.2.

Limiting syscalls with seccomp Legal Notice.

Generally, virtual machines are prevented from accessing parts of the network.

Specifically, individual virtual machines are denied access to one anothers resources.

The Docker SELinux role and Docker SELinux types are based on libvirt.

For example, by default, Docker has access to usrvar and some other locations, but it has complete access to things that are labeled with svirtsandboxfilet.

But if the containers write into a directory that has svirtsandboxfilet ownership, they write using their own category (which in this case is c186,c641).

If you start the same container twice, it will get a new category the second time ( a different category than it had the first time).

Each container is given a unique ID at startup, and each file that a container writes carries that unique ID.

Although this is an opt-in system, failure to make use of it means that you will have no isolation between containers.

If you do not make use of MCS, you will have isolation between containers and the host, but you will not have isolation of containers from one another.

That means that one container could access another containers files.

To give docker access to more than that, relabel content on the host.

To restrict access to things in usr or things in etc, relabel them.

If you want to restrict access to only one or two containers, then youll need to use the opt-in MCS system.

Even privileged docker processes cannot access arbitrary socket files.

An SElinux Boolean, dockerconnectany, makes it possible for privileged docker processes to access arbitrary socket files.

Capabilites constitute the heart of the isolation of containers.

If you have used capabilites in the manner described in this guide, an attacker who does not have a kernel exploit will be able to do nothing even if they have root on your system.

Docker For Mac Needs Privileged Access