Description of problem: sh# systemctl start rhel-push-plugin.service A dependency job for rhel-push-plugin.service failed. See 'journalctl -xe' for details. Nov 26 18:55:50 host audit[1]: AVC avc: denied { create } for pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service Nov 26 18:55:50 host systemd[1]: rhel-push-plugin.socket: Failed to listen on sockets: Permission denied Nov 26 18:55:50 host systemd[1]: Failed to listen on Docker Block RHEL push plugin Socket for the API. Nov 26 18:55:50 host systemd[1]: Dependency failed for Docker Block RHEL push plugin authZ Plugin. Nov 26 18:55:50 host systemd[1]: rhel-push-plugin.service: Job rhel-push-plugin.service/start failed with result 'dependency'. SELinux is preventing systemd from 'create' accesses on the unix_stream_socket Unknown. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd should be allowed create access on the Unknown unix_stream_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:system_r:unconfined_service_t:s0 Target Objects Unknown [ unix_stream_socket ] Source systemd Source Path systemd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-226.fc26.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.8.8-300.fc25.x86_64 #1 SMP Tue Nov 15 18:10:06 UTC 2016 x86_64 x86_64 Alert Count 6 First Seen 2016-11-26 18:51:15 CET Last Seen 2016-11-26 18:55:50 CET Local ID 309bb3bd-28b6-4995-8305-90147f79412f Raw Audit Messages type=AVC msg=audit(1480182950.829:704): avc: denied { create } for pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0 Hash: systemd,init_t,unconfined_service_t,unix_stream_socket,create Version-Release number of selected component: selinux-policy-3.13.1-226.fc26.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.8.8-300.fc25.x86_64 type: libreport Potential duplicate: bug 1379278
IMHO, It should be fixed in container-selinux
AVCs in permissive mode sh# systemctl start rhel-push-plugin.service sh# ausearch -m avc -ts recent -i type=AVC msg=audit(11/26/2016 19:03:02.610:708) : avc: denied { create } for pid=1 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 ---- type=AVC msg=audit(11/26/2016 19:03:02.610:709) : avc: denied { setopt } for pid=1 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 ---- type=AVC msg=audit(11/26/2016 19:03:02.610:710) : avc: denied { bind } for pid=1 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 ---- type=AVC msg=audit(11/26/2016 19:03:02.610:711) : avc: denied { listen } for pid=1 comm=systemd path=/run/docker/plugins/rhel-push-plugin.sock scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 sh# ps auxZ | grep rhel-push-plugi[n] system_u:system_r:unconfined_service_t:s0 root 7444 0.0 0.0 39488 7052 ? Ssl 19:03 0:00 /usr/libexec/docker/rhel-push-plugin
See also BZ1398860
having the same issue here on Rawhide, setenforce 0 makes this work again.
9de00853d884e47bae70ea6bc8b87ce1b4a2bab2 should fix this labeling issue in container-selinux package. Can you push a new docker package with this fix.
rebuilt with the above container-selinux commit: http://koji.fedoraproject.org/koji/buildinfo?buildID=820619
I still can see AVCs with the latest version sh# rpm -q docker container-selinux docker-1.12.3-24.git7b5044b.fc26.x86_64 container-selinux-1.12.3-24.git7b5044b.fc26.x86_64 sh# systemctl start rhel-push-plugin.service A dependency job for rhel-push-plugin.service failed. See 'journalctl -xe' for details. [root@graviton ~]# ausearch -m avc -ts recent -i ---- type=AVC msg=audit(11/28/2016 10:51:04.218:274) : avc: denied { create } for pid=1 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0 and in permissive mode type=AVC msg=audit(11/28/2016 10:51:57.911:278) : avc: denied { create } for pid=1 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 ---- type=AVC msg=audit(11/28/2016 10:51:57.911:279) : avc: denied { setopt } for pid=1 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 ---- type=AVC msg=audit(11/28/2016 10:51:57.911:280) : avc: denied { bind } for pid=1 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 ---- type=AVC msg=audit(11/28/2016 10:51:57.911:281) : avc: denied { listen } for pid=1 comm=systemd path=/run/docker/plugins/rhel-push-plugin.sock scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1
So, by installing the latest rawhide build on a fresh rawhide vm: [root@rawhide ~]# ls -laZ /run/docker/plugins/ total 0 drwxr-xr-x. 2 root root system_u:object_r:var_run_t:s0 60 Nov 28 10:03 . drwxr-xr-x. 5 root root system_u:object_r:var_run_t:s0 100 Nov 28 10:03 .. srw-rw-rw-. 1 root root system_u:object_r:var_run_t:s0 0 Nov 28 10:03 rhel-push-plugin.sock Note, it's labeled "var_run_t". BTW, I can successfully start docker and/or the rhel-push-plugin. Try: $ restorecon -vR /var/run/docker/plugins It should give you the correct label for sockets "container_plugin_var_run_t": [root@rawhide ~]# ls -laZ /run/docker/plugins/ total 0 drwxr-xr-x. 2 root root system_u:object_r:container_plugin_var_run_t:s0 60 Nov 28 10:03 . drwxr-xr-x. 5 root root system_u:object_r:var_run_t:s0 100 Nov 28 10:03 .. srw-rw-rw-. 1 root root system_u:object_r:container_plugin_var_run_t:s0 0 Nov 28 10:03 rhel-push-plugin.sock Dan, do you know why container-selinux isn't labeling files properly on installation?
(In reply to Antonio Murdaca from comment #8) > So, by installing the latest rawhide build on a fresh rawhide vm: > > [root@rawhide ~]# ls -laZ /run/docker/plugins/ > total 0 > drwxr-xr-x. 2 root root system_u:object_r:var_run_t:s0 60 Nov 28 10:03 . > drwxr-xr-x. 5 root root system_u:object_r:var_run_t:s0 100 Nov 28 10:03 .. > srw-rw-rw-. 1 root root system_u:object_r:var_run_t:s0 0 Nov 28 10:03 > rhel-push-plugin.sock > > Note, it's labeled "var_run_t". BTW, I can successfully start docker and/or > the rhel-push-plugin. > That's not the problem. I have correct labels [root@graviton ~]# ls -laZ /run/docker/plugins/ total 0 drwxr-xr-x. 2 root root system_u:object_r:container_plugin_var_run_t:s0 60 Nov 28 10:51 . drwx------. 6 root root system_u:object_r:container_var_run_t:s0 120 Nov 28 10:53 .. srw-rw-rw-. 1 root root system_u:object_r:container_plugin_var_run_t:s0 0 Nov 28 10:51 rhel-push-plugin.sock
(In reply to Lukas Slebodnik from comment #9) > (In reply to Antonio Murdaca from comment #8) > > So, by installing the latest rawhide build on a fresh rawhide vm: > > > > [root@rawhide ~]# ls -laZ /run/docker/plugins/ > > total 0 > > drwxr-xr-x. 2 root root system_u:object_r:var_run_t:s0 60 Nov 28 10:03 . > > drwxr-xr-x. 5 root root system_u:object_r:var_run_t:s0 100 Nov 28 10:03 .. > > srw-rw-rw-. 1 root root system_u:object_r:var_run_t:s0 0 Nov 28 10:03 > > rhel-push-plugin.sock > > > > Note, it's labeled "var_run_t". BTW, I can successfully start docker and/or > > the rhel-push-plugin. > > > That's not the problem. I have correct labels > [root@graviton ~]# ls -laZ /run/docker/plugins/ > total 0 > drwxr-xr-x. 2 root root system_u:object_r:container_plugin_var_run_t:s0 60 > Nov 28 10:51 . > drwx------. 6 root root system_u:object_r:container_var_run_t:s0 120 > Nov 28 10:53 .. > srw-rw-rw-. 1 root root system_u:object_r:container_plugin_var_run_t:s0 0 > Nov 28 10:51 rhel-push-plugin.sock well, it is an issue, at least on my virtual machine :) where I can successfully install and run docker w/o this denials you're having.
I've just realized that SELinux context was changed in binaries. Following command fixed the AVCs sh# restorecon -Rv /usr/libexec/docker/
We should add this command to the container-selinux post install script, to make sure its content gets labeled correctly.
(In reply to Daniel Walsh from comment #12) > We should add this command to the container-selinux post install script, to > make sure its content gets labeled correctly. Dan, do you mean something like this? https://paste.fedoraproject.org/491982/34191314/ Note, that restorecon will be run only on "installation" (not on upgrades)
Description of problem: systemctl start rpcbind.service Version-Release number of selected component: selinux-policy-3.13.1-227.fc26.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.8.11-300.fc25.x86_64 type: libreport
(In reply to Antonio Murdaca from comment #13) > (In reply to Daniel Walsh from comment #12) > > We should add this command to the container-selinux post install script, to > > make sure its content gets labeled correctly. > > Dan, do you mean something like this? > https://paste.fedoraproject.org/491982/34191314/ > > Note, that restorecon will be run only on "installation" (not on upgrades) Dan, what do we need to do here? Is it OK to relate files under libexec as I pointed out above?
Created attachment 1230250 [details] This patch should cause docker.rpm to relabel /usr/bin/docker* and /usr/libexec/docker
Antonio yes you can relabel the files under /usr/libexec/docker Which I do in the patch above.
docker-1.12.3-15.git0423d89.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-37c2c59240
docker-1.12.3-15.git0423d89.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-37c2c59240
docker-1.12.4-2.git1b5971a.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bb5ee53c0a
docker-1.12.4-5.git1b5971a.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2a18b9e056
docker-1.12.4-2.git1b5971a.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-bb5ee53c0a
docker-1.12.4-6.git1b5971a.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-44ed3dd527
docker-1.12.4-2.git1b5971a.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
docker-1.12.4-6.git1b5971a.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-44ed3dd527
docker-1.12.4-6.git1b5971a.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Reopening: this issue is still happening on a fully-updated Rawhide system: selinux-policy-3.13.1-236.fc26.noarch docker-1.12.6-17.git037a2f5.fc26.x86_64
Stephen could you please attach the AVC's you are seeing? I am not sure you are seeing the same issue? ps -eZ | grep docker
Created attachment 1248040 [details] AVCs (In reply to Daniel Walsh from comment #28) > Stephen could you please attach the AVC's you are seeing? I am not sure you > are seeing the same issue? > > ps -eZ | grep docker system_u:system_r:unconfined_service_t:s0 1843 ? 00:00:00 docker-containe system_u:system_r:unconfined_service_t:s0 1849 ? 00:00:01 dockerd-current Attached is the output of `audit2why -a` on my system. It may well not be the same bug, but SELinux Troubleshooter keeps marking it as a dupe, so there could well be a bug in that program as well...
This means container-selinux or something did not successfully install. dnf reinstall container-selinux If this does not fail then see if a relabel of /usr/bin/docker* works. restorecon -v /usr/bin/docker*
Also restart the docker and docker-containerd service after the relabel.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
Description of problem: upgrade from FC25 to FC26 then running dnf update caused this issue Version-Release number of selected component: selinux-policy-3.13.1-224.fc25.noarch Additional info: reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.11.0-2.fc26.x86_64 type: libreport
Description of problem: sudo dnf update -y Version-Release number of selected component: selinux-policy-3.13.1-224.fc25.noarch Additional info: reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.11.11-300.fc26.x86_64 type: libreport
Description of problem: It just happened in day to day use. I've only been using the web browser and doing normal system updates on Fedora 26. Version-Release number of selected component: selinux-policy-3.13.1-224.fc25.noarch Additional info: reporter: libreport-2.9.1 hashmarkername: setroubleshoot kernel: 4.11.11-300.fc26.x86_64 type: libreport
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.