SELinux doesn't contain Docker containers

[kh34]

Issue Report

Bug

I seem to have the same issue as #972

Container Linux Version

CoreOS-stable-1688.5.3-hvm (ami-9e2685e3)

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1688.5.3
VERSION_ID=1688.5.3
BUILD_ID=2018-04-03-0547
PRETTY_NAME="Container Linux by CoreOS 1688.5.3 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"
BUG_REPORT_URL="https://issues.coreos.com"

Environment

What hardware/cloud provider/hypervisor is being used to run Container Linux?

amazon ec2 CoreOS-stable-1688.5.3-hvm (ami-9e2685e3)

Expected Behavior

I expected docker to set the context from /etc/selinux/mcs/contexts/lxc_contexts just as rkt does.

system_u:system_r:svirt_lxc_net_t

Actual Behavior

docker always runs as kernel_t:

# docker run -v /etc:/test1 centos:7 sleep 10 &
# ps auxZ |grep sleep
system_u:system_r:kernel_t:s0   root      1434  0.0  0.5 298028 20636 pts/0    Sl   21:09   0:00 /run/torcx/bin/docker run -v /etc:/test1 centos:7 sleep 10
system_u:system_r:kernel_t:s0   root      1463  0.5  0.0   4328   632 ?        Ss   21:09   0:00 sleep 10

Reproduction Steps

1. Launch ec2 instance using ami-9e2685e3
2. Run commands above

Other Information

In the example above with docker, my container can write to the host's /etc directory, which is something I'm trying to prevent.

[glevand]

I'm currently working to update the SELinux support. The updated support should not allow this. I needed to fixup the kola tests for it. See coreos/mantle#839. For this specific case see the patch tests/docker: Add new test docker.sel-perm.

BTW, Container Linux runs SELinux in permissive mode by default, so even if SELinux was working correctly you would need to switch to enforcing mode for it to be denied.

[andythompson]

I've experienced this issue as well with enforcing mode set.

[frankgreco]

How does Tectonic accomplish this then? Or are all tectonic clusters not secured with selinux?

[glevand]

@andythompson As kh34 mentioned, with the current SELinux policy the docker daemon is running with kernel_t permissions, so it will be able to do anything kernel_t permissions allow regardless of what mode SELinux is in. The updated policy has the docker daemon running with svirt_lxc_file_t, and there is a feature request to update the container related part of the policy to use container-selinux from project atomic. See #2231 (Docker SELinux policy should more closely match upstream).

@kh34 If there is something you want to protect I recommend you mount it as read-only; docker run -v /etc:/etc:ro See: https://docs.docker.com/storage/volumes/#use-a-read-only-volume. This is what you'll need to do with the new policy anyway since the new policy does not allow the docker daemon to create a container with a read-write mount to a read-only resource.

[frankgreco]

@glevand I'm not sure that solution is satisfactory in the context of Kubernetes. According to your solution, I would need to verify that every Kubernetes configuration that is applied to my cluster has the read only option set for the host paths that I want to secure.

With SELinux, I should just be able to create a rule and that location will be secured for me.

[glevand]

Found something related here: #1664. So it seems this once worked.

[dmrit]

Ran into this same issue in 1745.7.0. MCS labels look like they're applied if we're using docker 1.12 by setting /etc/coreos/docker-1.12, but they're not applied with docker 18.03.1-ce (or 17.09 from an earlier test). I saw this on:

NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1745.7.0
VERSION_ID=1745.7.0
BUILD_ID=2018-06-14-0909
PRETTY_NAME="Container Linux by CoreOS 1745.7.0 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

From docker version, I get

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   9ee9f40
  Built:        Thu Apr 26 04:27:49 2018
  OS/Arch:      linux/amd64
  Experimental: false

and running a container I don't see the expected labels:

core@coretest ~ $ docker run -d nginx
core@coretest ~ $ ps -efZ | grep nginx
system_u:system_r:kernel_t:s0   root      1326  1310  0 21:28 ?        00:00:00 nginx: master process nginx -g daemon off;
system_u:system_r:kernel_t:s0   101       1355  1326  0 21:28 ?        00:00:00 nginx: worker process

If I switch to docker 1.12 following the steps mentioned in https://coreos.com/blog/toward-docker-17-in-container-linux, instead it's

Server:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.7.6
 Git commit:   d9ad3fc
 Built:        Thu Jun 14 08:36:44 2018
 OS/Arch:      linux/amd64

and running the same container, I see

core@coretest ~ $ docker run -d nginx
core@coretest ~ $ ps -efZ | grep nginx
system_u:system_r:svirt_lxc_net_t:s0:c421,c516 root 897 880  1 21:30 ? 00:00:00 nginx: master process nginx -g daemon off;
system_u:system_r:svirt_lxc_net_t:s0:c421,c516 101 932 897  0 21:30 ?  00:00:00 nginx: worker process

@glevand Is it expected right now that selinux labels are applied in coreos with docker 1.12 but not with 17.09-ce+ until the policy fix mentioned above goes in?

[tbennett0]

Bump for visibility. This is a crucial security piece for using Docker securely.

CC: @ajeddeloh

Thanks!

[bgilbert]

Thank you for reporting this issue. Unfortunately, we don't think we'll end up addressing it in Container Linux.

We're now working on Fedora CoreOS, the successor to Container Linux, and we expect most major development to occur there instead. Meanwhile, Container Linux will be fully maintained into 2020 but won't see many new features. We appreciate your taking the time to report this issue and we're sorry that we won't be able to address it.

[bgilbert]

For context: adding additional confinement to the SELinux policy is likely to break existing systems with enforcing enabled, and we're trying to avoid breaking changes at this point in Container Linux's lifecycle.