Bug 1413239 - docker run fails when attempting to run container with SELinux spc_t type
Summary: docker run fails when attempting to run container with SELinux spc_t type
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: atomic-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-14 01:33 UTC by Sam Ghods
Modified: 2019-03-06 00:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-06-30 15:08:28 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Sam Ghods 2017-01-14 01:33:48 UTC
Description of problem:

Trying to run a Docker container with customizing the SELinux type to spc_t in order to let it access files in host paths fails:

[sam@compute-node10.dev ~]$ sudo docker run --security-opt="label:type:spc_t" -ti -v /box/etc/pki:/box/etc/pki box-registry.jfrog.io/jenkins/centos
4.27 bash
permission denied
docker: Error response from daemon: Container command could not be invoked..

In the Docker logs:

Jan 12 15:47:04 compute-node10.dev.box.net kernel: SELinux: mount invalid.  Same superblock, different security settings for (dev mqueue, type mqueue)
Jan 12 15:47:04 compute-node10.dev.box.net docker-current[3888]: permission denied

But, if we try to run with container_runtime_t type, it works:

[sam@compute-node10.dev ~]$ sudo docker run --security-opt="label:type:container_runtime_t" -ti -v /box/etc/pki:/box/etc/pki box-registry.jfrog.io/jenkins/centos
016.10.27_23.54.27 bash

That container is also able to access a host mount like /tmp, even though regular containers cannot (as expected).

Is spc_t still the right type to use here? Should I be using container_runtime_t instead, or is that too many privileges?

Version-Release number of selected component (if applicable):

OS: CentOS 7.3.1611 kernel 3.10.0-514.2.2.el7.x86_64

How reproducible: 100%

Comment 2 Daniel Walsh 2017-01-16 15:38:13 UTC
Are you seeing AVC's?  There was a bug in container-selinux which was causing this issue, I believe that this will be fixed in the next release.

Comment 3 Sam Ghods 2017-01-20 22:33:41 UTC
Yes, from audit.log:

node=compute-node10 type=AVC msg=audit(1484951512.650:2130331): avc:  denied  { entrypoint } for  pid=25701 comm="exe" path="/bin/bash" dev="dm-20" ino=4194817 scontext=system_u:system_r:spc_t:s0:c567,c997 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c567,c997 tclass=file

Does it look like the issue? Any estimate on when the next container-selinux release will be out?

Comment 4 Daniel Walsh 2017-01-25 20:25:17 UTC
It was released last week with docker-1.12

Comment 5 Sam Ghods 2017-01-25 22:08:50 UTC
Cool, thank you! Will there be a patch for 1.10?

Comment 6 Daniel Walsh 2017-01-25 22:27:32 UTC
The updated container-selinux package should fix it for docker-1.10, but I am not sure you can install only this without updating docker.

Comment 7 Sam Ghods 2017-01-25 22:41:36 UTC
The current packages I see in the CentOS extras repo is:

container-selinux-1.10.3-59.el7.centos.x86_64.rpm	15-Dec-2016
container-selinux-1.12.5-14.el7.centos.x86_64.rpm	23-Jan-2017
docker-1.10.3-59.el7.centos.x86_64.rpm			15-Dec-2016
docker-1.12.5-14.el7.centos.x86_64.rpm			23-Jan-2017

So I wonder if container-selinux-1.10.3 will have another release with this fix? Or do I have to go all the way to 1.12 to get it?

Comment 8 Sam Ghods 2017-01-25 23:02:41 UTC
I ask because the upgrade to 1.12 for us is rather disruptive and will take a few weeks of internal testing, but I can do the 1.10 upgrade much more easily.

Comment 9 Daniel Walsh 2017-01-26 06:05:33 UTC
container-selinux should be agnostic to the docker release.  We are splitting up the packages so that container-selinux will have a different life then docker.  Bottom line, you should be able to run docker-1.10 with a container-selinux-1.12, unless the RPMs screw it up.

Comment 10 Steven Walter 2017-03-23 16:31:54 UTC
I have a customer I believe may be hitting this, but is slightly inconsistent with what I've read in this bug.


They hit the issue even after installing container-selinux-1.12.5:

yum swap -y -- install container-selinux-1.12.5 -- remove container-selinux-2.9

then we have rebooted the server but we still have the issue :

[root@master2 ~]# dmesg -T|grep -i super
[jeu. mars 23 08:48:44 2017] SELinux:  Setting up existing superblocks.
[jeu. mars 23 08:49:22 2017] SELinux: mount invalid.  Same superblock, different security settings for (dev mqueue, type mqueue)
[jeu. mars 23 08:49:23 2017] SELinux: mount invalid.  Same superblock, different security settings for (dev mqueue, type mqueue)

Am I hitting this bug or is this something different, do you think?

Comment 11 Daniel Walsh 2017-03-27 13:11:42 UTC
Those are just warnings and can be ignored, eventually there will be an updated kernel with support for labeling on /dev/mqueue.    Do the containers work in enforcing mode?

Comment 12 Sam Ghods 2017-03-27 18:46:36 UTC
In my case they do seem to work in enforcing mode.

Note You need to log in before you can comment on or make changes to this bug.