Linux – How to disallow the Docker Daemon to mount host’s root file system into the container

apparmorchrootdockerlinuxselinux

I have the following Container Setup.

On a bare metal server two Docker Daemons are installed and running.

Main Docker Daemon Runs my application containers exposing 80/443 to the outside world.
Plugin Docker Daemon Runs some containers provided by the customer that communicate with my application via 80/443.

I would like give the customer access to the API (2376) of the Plugin Docker Daemon so that the customer can deploy/start/stop his own containers. The customer will only have access to the API not to the Host (SSH).

The problem I currently face is, what if the customers runs a container that does something insecure like docker run -v /:/host/root Ubuntu rm -rf /host/root.

My question is what can I do to prevent the Plugin Docker Daemon from mounting root / or any other directory outside /home/user/,

Is it an option to start the Docker Daemon in /home/user/?
Can I use some LSM (Linux Security Modules SELinux/Apparmor) magic to prevent the docker daemon to mount some or all host paths except users home or var/docker/libs?
Can --userns-remap help me to achieve my goal?
Are they any other options available except VMs?

The server belongs entirely to a single customer. So security or data leakage is not my primary concern. What I really want to prevent is that someone in Plugin Daemon is doing something stupid, that influences my containers that run in Main Docker Daemon. I would like to keep lean and stick to docker only workflow and don't won't to set up an extra workflow for VM creation.

Best Answer

SELinux will prevent anything not correctly labelled to be mounted as a volume inside a docker container, as proof, here using a single file, same policy applies to directories:

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      30

Using the sample file:

$ cat sample_script.sh 
echo 'Hello, world'

Its default security context is:

$ ls -lrtZ sample_script.sh 
-rw-------. 1 david david unconfined_u:object_r:user_home_t:s0 20 Oct  3 17:18 sample_script.sh

Trying to use this file inside a container fails as expected:

$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.sh
bash: sample_script.sh: Permission denied

And an AVC denial will be logged:

$ sudo ausearch -m avc -ts recent
time->Mon Oct  3 17:39:28 2016
type=AVC msg=audit(1475512768.444:784): avc:  denied  { read } for  pid=28720 comm="bash" name="sample_script.sh" dev="dm-13" ino=101062112 scontext=system_u:system_r:svirt_lxc_net_t:s0:c457,c992 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0

After changing the security context to one Docker can use:

$ sudo chcon -Rt svirt_sandbox_file_t sample_script.sh
$ ls -lrtZ sample_script.sh 
-rw-------. 1 david david unconfined_u:object_r:svirt_sandbox_file_t:s0 20 Oct  3 17:18 sample_script.sh

The container now has access to the file:

$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.sh
Hello, world

More information about Docker and SELinux in the official Red Hat documentation and this article by Dan Walsh.

Related Solutions

Ssh – Restricting the network access of Docker container

It still makes sense to put some ingress rules inside your docker instance to help ward off attacks, but you will have to limit outbound (Internet) access from whatever upstream router the docker image connects with. The reason for this is, if you try to block outbound access with the firewall rules inside your instance, then if the instance is compromised those rules could be removed by the attacker. By blocking egress via the instance's router, you block outbound access even in the event of a compromise - the attacker would have to compromise the router as well.

Ok, so after receiving some commentary that explains that the filtering was intended for the container's host, it's a little clearer what is trying to be accomplished. In which case, on the host, you would add some rules similar to this:

iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT
iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -j DROP

The first two rules are for access between the host and the container. The third rule says (roughly) that anything that isn't the host's subnet headed for SFTP is just OK by us; the fourth is the outbound rule that is basically a twin to the third; the fifth rule is a catch-all (in case there are other related ports that are used), although it shouldn't be needed, you could probably remove it; the last rule is the magic on that prevents access to anything other than the host subnet. Because access is given in the first few rules, it will never trigger unless none of the preceding rules apply, in which case we are saying "we don't care what you want, you didn't match anything you're approved for, so you can't get there from here". Inbound traffic from the outside will be satisfied by the 3rd and 4th rules.

Docker – How does yum with Red Hat Network Subscription work inside the rhel Docker images

Red Hat carries a patch to docker called the 'secrets' patch which mounts the entitlement information into containers when they are run.

You can see the a better description of the patch and a link to the upstream PR in the projectatomic/docker repo:

https://github.com/projectatomic/docker/tree/docker-1.13.1-rhel#add-rhel-super-secrets-patchpatch

Note, you'll need to select one of the branches (the link goes to the 'docker-1.3.1-rhel' branch) to see all the carried patch information.

Best Answer

Related Solutions

Ssh – Restricting the network access of Docker container

Docker – How does yum with Red Hat Network Subscription work inside the rhel Docker images

Related Topic