Description of problem: [root@qeos-11 ~]# rpm -q docker selinux-policy container-selinux docker-1.13.1-59.gitaf6b32b.fc28.x86_64 selinux-policy-3.14.1-32.fc28.noarch container-selinux-2.65-1.gitbf5b26b.fc28.noarch [root@qeos-11 ~]# cat Dockerfile FROM fedora:28 ENV LANG C ARG type=local RUN echo "OK" [root@qeos-11 ~]# docker build . Sending build context to Docker daemon 28.16 kB Step 1/4 : FROM fedora:28 ---> cc510acfcd70 Step 2/4 : ENV LANG C ---> Using cache ---> 6461f8e5ed26 Step 3/4 : ARG type=local ---> Using cache ---> fbedd1023bf4 Step 4/4 : RUN echo "OK" ---> Running in bf1cab82a539 The command '/bin/sh -c echo "OK"' returned a non-zero code: 139 [root@qeos-11 ~]# setenforce 0 [root@qeos-11 ~]# docker build . Sending build context to Docker daemon 28.67 kB Step 1/4 : FROM fedora:28 ---> cc510acfcd70 Step 2/4 : ENV LANG C ---> Using cache ---> 6461f8e5ed26 Step 3/4 : ARG type=local ---> Using cache ---> fbedd1023bf4 Step 4/4 : RUN echo "OK" ---> Running in 03b8a88f29b9 OK ---> b12258b89189 Removing intermediate container 03b8a88f29b9 Successfully built b12258b89189 [root@qeos-11 ~]# cat /var/log/audit/audit.log | audit2allow #============= container_t ============== allow container_t container_file_t:chr_file { open read write }; allow container_t var_lib_t:file { execute map open read }; [root@qeos-11 ~]# [root@qeos-11 ~]# ausearch -m avc ---- time->Fri Jun 29 04:12:51 2018 type=AVC msg=audit(1530259971.982:361): avc: denied { map } for pid=18234 comm="sh" path="/usr/bin/bash" dev="vda1" ino=262862 scontext=system_u:system_r:container_t:s0:c244,c900 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1 ---- time->Fri Jun 29 04:12:51 2018 type=AVC msg=audit(1530259971.982:362): avc: denied { read execute } for pid=18234 comm="sh" path="/usr/bin/bash" dev="vda1" ino=262862 scontext=system_u:system_r:container_t:s0:c244,c900 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1 ---- time->Fri Jun 29 04:12:51 2018 type=AVC msg=audit(1530259971.982:363): avc: denied { open } for pid=18234 comm="sh" path="/etc/ld.so.cache" dev="vda1" ino=262412 scontext=system_u:system_r:container_t:s0:c244,c900 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1 ---- time->Fri Jun 29 04:12:51 2018 type=AVC msg=audit(1530259971.983:364): avc: denied { read write } for pid=18234 comm="sh" name="tty" dev="tmpfs" ino=49025 scontext=system_u:system_r:container_t:s0:c244,c900 tcontext=system_u:object_r:container_file_t:s0:c244,c900 tclass=chr_file permissive=1 ---- time->Fri Jun 29 04:12:51 2018 type=AVC msg=audit(1530259971.983:365): avc: denied { open } for pid=18234 comm="sh" path="/dev/tty" dev="tmpfs" ino=49025 scontext=system_u:system_r:container_t:s0:c244,c900 tcontext=system_u:object_r:container_file_t:s0:c244,c900 tclass=chr_file permissive=1
found bug 1440875... setting the boolean didn't help. [root@qeos-11 ~]# setsebool -P virt_sandbox_use_fusefs 1 [root@qeos-11 ~]# getsebool virt_sandbox_use_fusefs virt_sandbox_use_fusefs --> on [root@qeos-11 ~]# docker build . Sending build context to Docker daemon 28.67 kB Step 1/4 : FROM fedora:28 ---> cc510acfcd70 Step 2/4 : ENV LANG C ---> Using cache ---> 6461f8e5ed26 Step 3/4 : ARG type=local ---> Using cache ---> fbedd1023bf4 Step 4/4 : RUN echo "OKK" ---> Running in f26fca332bd4 The command '/bin/sh -c echo "OKK"' returned a non-zero code: 139
Looks like you have a labeling issue. restorecon -R -v /var/lib/docker Should clean it up. I beieve the overlay directory is mislabeled. BTW Have you tried podman.
reopening.
Created attachment 1455493 [details] console log Attaching the console log. The system was not mislabeled prior the docker installation.
in the log above focus on the container-selinux scriptlet failure Running scriptlet: container-selinux-2:2.65-1.gitbf5b26b.fc28.noarch 13/24 neverallow check failed at /var/lib/selinux/targeted/tmp/modules/100/base/cil:9183 (neverallow base_typeattr_7 unlabeled_t (file (entrypoint))) <root> allow at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1554 (allow spc_t unlabeled_t (file (entrypoint))) <root> allow at /var/lib/selinux/targeted/tmp/modules/100/sandboxX/cil:866 (allow sandbox_x_domain exec_type (file (entrypoint))) <root> allow at /var/lib/selinux/targeted/tmp/modules/100/virt/cil:1677 (allow virtd_lxc_t exec_type (file (entrypoint))) <root> allow at /var/lib/selinux/targeted/tmp/modules/100/virt/cil:2068 (allow svirt_sandbox_domain exec_type (file (entrypoint))) Failed to generate binary /usr/sbin/semodule: Failed!
This is a libsemanage issue. What libsemanage package do you have installed? # rpm -q libsemanage libsemanage-2.8-2.fc28.x86_64 #rpm -qV libsemanage # To make sure /etc/selinux/semanage.conf has not been changed. If you don't have that version install it from updates-testing # yum -y update libsemanage --enablerepo=updates-testing libsemanage # grep ^expand /etc/selinux/semanage.conf expand-check=0 expand-check should be '0' yum -y reinstall container-selinux
I did have libsemanage-2.7-12. I already realized that updating to the latest version fixes the scriptlet issue. But it seems to me rather a container-selinux bug as it should ensure through package requires that sufficient package versions are present when scriptlets are executed.
I did not even knot that the back package existed, before the release. I have no idea how that package got out. When I found out about it I scrambled to get someone to fix it, and they have fixed it. I am not going to force every package that ships selinux policy to recreate their package since a bad version of the SELinxu tool chain got released. This libsemanage actually broke the selinux-policy package as well.
Ah, I see. I am sorry, I thought that the failure is due to container-selinux using new functionality from libsemanage, not due to a regression in libsemanage. Thank you for explaining that.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. 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 '28'. 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 28 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 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 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.