Bug 1413536

Summary: container-selinux does not update labels during upgrade
Product: Red Hat Enterprise Linux 7 Reporter: Marko Myllynen <myllynen>
Component: dockerAssignee: Lokesh Mandvekar <lsm5>
Status: CLOSED ERRATA QA Contact: atomic-bugs <atomic-bugs>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 7.3CC: amurdaca, bkozdemb, brubisch, dwalsh, gkf42, imcleod, jbaird, lsm5, lsu, mark.vinkx, rhowe, sdodson, sreber, stwalter
Target Milestone: rcKeywords: Extras
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-02 00:11:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1186913, 1422984    

Description Marko Myllynen 2017-01-16 10:26:55 UTC
Description of problem:
[root@master01 ~]# rpm -q container-selinux
container-selinux-1.10.3-59.el7.x86_64
[root@master01 ~]# restorecon -v /usr/bin/runcon
[root@master01 ~]# rpm -Fvh container-selinux-1.12.5-14.el7.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:container-selinux-2:1.12.5-14.el7################################# [ 50%]
Cleaning up / removing...
   2:container-selinux-2:1.10.3-59.el7################################# [100%]
[root@master01 ~]# restorecon -v /usr/bin/runcon
restorecon reset /usr/bin/runcon context system_u:object_r:bin_t:s0->system_u:object_r:container_runtime_exec_t:s0
[root@master01 ~]#

Comment 2 Daniel Walsh 2017-01-16 18:01:28 UTC
Antonio or Lokesh can you add this to the relabel in the spec file

Comment 3 Antonio Murdaca 2017-01-16 18:08:40 UTC
is it right that /usr/bin/runcon has a container_runtime_exec_t label though? (just wondering). Dan, do we need this in Fedora as well? (since I'm able to reproduce this)

Comment 4 Lokesh Mandvekar 2017-01-16 18:16:52 UTC
runcon is provided by the coreutils package. I guess this should be fixed by the selinux-policy package. Dan, correct me if I'm wrong.

Comment 5 Daniel Walsh 2017-01-17 21:59:16 UTC
We should not be labeling runcon, this looks like it was supposed to label runc, not runcon.

Comment 6 Daniel Walsh 2017-01-17 22:02:48 UTC
I have updated the labeling on container-selinux for master and RHEL-1.12 branch

Now we should only set the label on runc.

-/usr/bin/runc.*                        --      gen_context(system_u:object_r:container_runtime_exec_t,s0)
+/usr/bin/runc                  --      gen_context(system_u:object_r:container_runtime_exec_t,s0)

Regex was too liberal.

Comment 7 Steven Walter 2017-02-06 19:26:08 UTC
Raising severity to urgent based on a customer experiencing an outage in their OpenShift cluster after update to these selinux-policy packages:

selinux-policy-devel-3.13.1-102.el7_3.7.noarch
selinux-policy-targeted-3.13.1-102.el7_3.7.noarch
selinux-policy-3.13.1-102.el7_3.7.noarch

The relabeling did not occur properly. They were able to fix it by running:

$ yum reinstall -y container-selinux; systemctl restart docker; systemctl restart atomic-openshift-node

Given that these labeling issues can cause outages with a simple yum update this should be considered a high priority.

Comment 8 Josh Baird 2017-02-09 16:19:58 UTC
I also experienced this same issue after upgrading an OCP cluster from 3.3 to 3.4 and updating to the following packages:

selinux-policy-devel-3.13.1-102.el7_3.13.noarch
selinux-policy-targeted-3.13.1-102.el7_3.13.noarch
container-selinux-1.12.5-14.el7.x86_64

The only way to fix this was to 'yum reinstall container-selinux' and force a relabel/reboot.

Comment 9 Daniel Walsh 2017-02-09 16:53:08 UTC
Josh, the issue you are seeing and this issue are two different things.  This issue is we accidently labeled runcon as a container runtime, when it should be bin_t.

What you are seeing is a conflict between container-selinux and the older docker-selinux package, which is not being installed in the correct order because of dependencies.  The current container-selinux container-selinux-2.7-1.el7 which is working its way through the RHEL process should fix these issues.  But will not be shipped for a few more weeks.

Comment 10 Daniel Walsh 2017-02-09 16:53:35 UTC
Fixed in container-selinux-2.7-1.el7

Comment 11 Steven Walter 2017-02-17 15:07:42 UTC
I am having a problem with the workaround (yum reinstall container-selinux) -- after doing so it did not relabel the contents of /usr/bin/docker*. I tried to manually relabel:


# chcon -t container_runtime_exec_t /usr/bin/docker*
chcon: failed to change context of ‘/usr/bin/docker’ to ‘system_u:object_r:container_runtime_exec_t:s0’: Invalid argument

Looks like the label doesn't exist:

# semanage fcontext -l | grep container
/usr/lib/xulrunner[^/]*/plugin-container           regular file       system_u:object_r:mozilla_plugin_exec_t:s0 
/var/run/containerd(/.*)?                          all files          system_u:object_r:docker_var_run_t:s0 
/var/lib/containers/home(/.*)?                     all files          system_u:object_r:openshift_var_lib_t:s0 
/var/lib/docker/containers/.*/hosts                all files          system_u:object_r:docker_share_t:s0 
/var/lib/docker/containers/.*/.*\.log              all files          system_u:object_r:docker_log_t:s0 
/var/lib/docker/containers/.*/hostname             all files          system_u:object_r:docker_share_t:s0 
/var/lib/docker-latest/containers/.*/hosts         all files          system_u:object_r:docker_share_t:s0 
/var/lib/docker-latest/containers/.*/.*\.log       all files          system_u:object_r:docker_log_t:s0 
/var/lib/docker-latest/containers/.*/hostname      all files          system_u:object_r:docker_share_t:s0 
/usr/bin/swift-container-sync                      regular file       system_u:object_r:swift_exec_t:s0 
/usr/bin/swift-container-server                    regular file       system_u:object_r:swift_exec_t:s0 
/usr/bin/swift-container-auditor                   regular file       system_u:object_r:swift_exec_t:s0 
/usr/bin/swift-container-updater                   regular file       system_u:object_r:swift_exec_t:s0 
/usr/lib/firefox/plugin-container                  regular file       system_u:object_r:mozilla_plugin_exec_t:s0 
/usr/bin/swift-container-replicator                regular file       system_u:object_r:swift_exec_t:s0 
/usr/bin/swift-container-reconciler                regular file       system_u:object_r:swift_exec_t:s0 

But container-selinux is installed!

# yum list installed container-selinux
Loaded plugins: langpacks, package_upload, product-id, search-disabled-repos, subscription-manager
Installed Packages
container-selinux.x86_64                                                       2:1.12.5-14.el7                                                       @rhel-7-server-extras-rpms
# yum list installed docker-selinux
Loaded plugins: langpacks, package_upload, product-id, search-disabled-repos, subscription-manager
Error: No matching Packages to list

Am I missing something in this workaround? Is this something that will be fixed when this bug is fixed or would I potentially still run into the same problem?

Comment 20 Daniel Walsh 2017-02-22 18:46:12 UTC
Are these upgrades breaking with the newer container-selinux package?

Comment 22 Daniel Walsh 2017-02-24 17:18:24 UTC
The package we are planning on shipping for container-selinux is

container-selinux-2.9-4.el7               extras-rhel-7.3-candidate  lmandvek

Comment 23 Marko Myllynen 2017-03-03 11:38:20 UTC
(In reply to Daniel Walsh from comment #20)
> Are these upgrades breaking with the newer container-selinux package?

[root@lb03 ~]# rpm -q container-selinux
container-selinux-1.12.5-14.el7.x86_64
[root@lb03 ~]# restorecon /usr/bin/runcon
[root@lb03 ~]# rpm -Uvh container-selinux-2.9-4.el7.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:container-selinux-2:2.9-4.el7    ################################# [ 50%]
Cleaning up / removing...
   2:container-selinux-2:1.12.5-14.el7################################# [100%]
[root@lb03 ~]# restorecon -v /usr/bin/runcon
restorecon reset /usr/bin/runcon context system_u:object_r:container_runtime_exec_t:s0->system_u:object_r:bin_t:s0
[root@lb03 ~]#

Comment 24 Daniel Walsh 2017-03-03 13:57:31 UTC
That looks good.

Comment 28 markv 2017-03-21 12:51:20 UTC
One of the step during manuel upgrade of openshift to 3.4 is an upgrade of docker.  yum update docker  see https://docs.openshift.com/container-platform/3.4/install_config/upgrading/manual_upgrades.html


it gives an error on the container-selinux install
  Updating   : 2:docker-rhel-push-plugin-1.12.6-11.el7.x86_64   4/14
  Updating   : 1:oci-register-machine-0-1.11.gitdd0daef.el7.x86_64  5/14
  Installing : 1:skopeo-containers-0.1.18-1.el7.x86_64     6/14
  Installing : 2:container-selinux-2.9-4.el7.noarch  7/14
/usr/sbin/semodule: invalid option -- 'X'
  Updating   : 2:docker-1.12.6-11.el7.x86_64  8/14
  Cleanup    : docker-1.10.3-46.el7.14.x86_64   9/14
  Cleanup    : docker-common-1.10.3-46.el7.14.x86_64    10/14
  Erasing    : docker-selinux-1.10.3-46.el7.14.x86_64 11/14
  Cleanup    : docker-rhel-push-plugin-1.10.3-46.el7.1

there is a depenceny on a newer version of policycoreutils
I had to upgrade it to policycoreutils-2.5-11.el7_3.x86_64 

This depency should be checked during install

Comment 29 Daniel Walsh 2017-03-21 13:31:37 UTC
This is fixed in container-selinux-2.10-2.el7

Comment 31 Luwen Su 2017-07-22 16:08:53 UTC
Verified in container-selinux-2.21-1.el7.noarch
and /usr/bin/runcon has right label that is no related with container.
ls -aZ /usr/bin/runcon 
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/bin/runcon

Comment 33 errata-xmlrpc 2017-08-02 00:11:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2344