Hide Forgot
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 ~]#
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