Antonio or Lokesh can you add this to the relabel in the spec file

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)

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.

We should not be labeling runcon, this looks like it was supposed to label runc, not runcon.

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.

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.

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.

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.

Fixed in container-selinux-2.7-1.el7

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?

Are these upgrades breaking with the newer container-selinux package?

The package we are planning on shipping for container-selinux is

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

(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 ~]#

That looks good.

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

This is fixed in container-selinux-2.10-2.el7

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

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