Description of problem: An SELinux denial is preventing me from running any docker container. After disabling SELinux (setenforce 0) the containers run just fine. The problem only appeared recently, I was able to run containers just fine until last week or so (on F27, before upgrade). Version-Release number of selected component (if applicable): container-selinux.noarch 2:2.55-1.fc28 @fedora docker.x86_64 2:1.13.1-51.git4032bd5.fc28 @fedora How reproducible: I have two separate systems with this bug, one with F28 and another one still on F27. I was not able to reproduce it with the F28 live image. Steps to Reproduce: 1. docker run --rm -it centos:7 /bin/sh Actual results: [root@fedora ~]# docker run --rm -it centos:7 /bin/sh [root@fedora ~]# echo $? 0 Info from SETroubleshoot: --- SELinux is preventing sh from 'read, write' accesses on the chr_file tty. [...] Raw Audit Messages type=AVC msg=audit(1526135524.946:807): avc: denied { read write } for pid=16479 comm="sh" name="tty" dev="tmpfs" ino=301826 scontext=system_u:system_r:container_t:s0:c234,c488 tcontext=system_u:object_r:container_file_t:s0:c234,c488 tclass=chr_file permissive=0 Hash: sh,container_t,container_file_t,chr_file,read,write --- Expected results: Drop to shell from docker container. Additional info: There is an error when running "dnf reinstall container-selinux": --- [...] Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Reinstalling : container-selinux-2:2.55-1.fc28.noarch 1/2 Running scriptlet: container-selinux-2:2.55-1.fc28.noarch 1/2 libsemanage.semanage_direct_commit: semanage_genhomedircon returned error code -1. (Connection timed out). /usr/sbin/semodule: Failed! Erasing : container-selinux-2:2.55-1.fc28.noarch 2/2 Running scriptlet: container-selinux-2:2.55-1.fc28.noarch 2/2 Verifying : container-selinux-2:2.55-1.fc28.noarch 1/2 Verifying : container-selinux-2:2.55-1.fc28.noarch 2/2 Reinstalled: container-selinux.noarch 2:2.55-1.fc28 Complete! --- The home dir of both affected systems is a bind mount, I don't know whether this could have something to do with it.
It seems to be a regression compared to version 2.52, as downgrading to container-selinux-2.52-1.fc27 and re-loading the module with semodule -i fixes the bug.
This looks like you are volume mounting a device from the host into the container, this device was previously labeled to run with a different container? What is the docker command you are executing?
This happens with any docker container, regardless of whether it has volumes or not. For example, running docker run --rm -it centos:7 /bin/sh produces type=AVC msg=audit(1526363071.674:309): avc: denied { read write } for pid=4816 comm="sh" path="/2" dev="devpts" ino=5 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0 type=AVC msg=audit(1526363071.674:310): avc: denied { read write } for pid=4816 comm="sh" path="/2" dev="devpts" ino=5 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0 type=AVC msg=audit(1526363071.674:311): avc: denied { read write } for pid=4816 comm="sh" path="/2" dev="devpts" ino=5 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0 type=AVC msg=audit(1526363071.674:312): avc: denied { read write } for pid=4816 comm="sh" path="/2" dev="devpts" ino=5 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0 type=AVC msg=audit(1526363071.685:314): avc: denied { read write } for pid=4816 comm="sh" name="tty" dev="tmpfs" ino=60022 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0
Looks like you somehow got your ttys mislabeled? On Host ls -lZ /dev/pts/ total 0 crw--w----. 1 dwalsh tty unconfined_u:object_r:user_devpts_t:s0 136, 0 May 15 10:23 0 crw--w----. 1 dwalsh tty unconfined_u:object_r:user_devpts_t:s0 136, 1 May 8 08:08 1 crw--w----. 1 dwalsh tty unconfined_u:object_r:user_devpts_t:s0 136, 2 May 8 07:54 2 crw--w----. 1 dwalsh tty unconfined_u:object_r:user_devpts_t:s0 136, 3 May 8 08:40 3 crw--w----. 1 dwalsh tty unconfined_u:object_r:user_devpts_t:s0 136, 4 May 15 09:48 4 c---------. 1 root root system_u:object_r:devpts_t:s0 5, 2 Apr 20 05:18 ptmx
Apart from the fact that I only have one it is similar to yours: [root@fedora user]# ls -lZ /dev/pts/ total 0 crw--w----. 1 user tty unconfined_u:object_r:user_devpts_t:s0 136, 0 May 15 18:51 0 c---------. 1 root root system_u:object_r:devpts_t:s0 5, 2 May 15 14:52 ptmx
find /dev -context "*:container_file_t:*" Does this show anything? If not find / -context "*:container_file_t:s0:c233,c993"
No, they both don't find anything: [root@fedora user]# find /dev -context "*:container_file_t:*" [root@fedora user]# find / -context "*:container_file_t:s0:c233,c993" find: ‘/run/user/1000/gvfs’: Permission denied I just noticed that after running "semodule -i /usr/share/selinux/packages/container.pp.bz2" it is working again. When I remove it again with "semodule -X 400 -r container" it is still working. I upgraded the second system and tried the same there, it is working too. Not sure what the problem was, could it be that the policy was not loaded correctly on upgrade?
I doubt it, from the AVC's you reported it definitely looked like one containers tty's leaking into another containers. Anyways if you can't get this to happen again. I guess we can close the bugzilla until it does happen again.
Sounds good, thanks a lot for your help! There were definitely no other containers though, I wasn't able to start any until today.