RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-14 01:33 UTC by Sam Ghods
Modified: 2023-03-24 13:45 UTC (History)
3 users (show)

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

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 ~]$ 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 ~]$ 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
bash-4.1#

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):

docker-1.10.3-59.el7.centos.x86_64
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.

docker-1.10.3-59.el7.x86_64

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.