Description of problem: 1. i used docker-compose and instructions from https://github.com/nextcloud/docker/tree/master/.examples#with-nginx-proxy to install nextcloud with nginx proxy and letsencrypt companion. it should be possible to reproduce with a simpler setup - e.g. follow the 3 steps at https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion#basic-usage-with-the-nginx-proxy-container 2. get that working with container-selinux 2.79. 3. upgrade to 2.80. It looks like container-selinux-2:2.80-1.git1b655d9.fc29 breaks the inter-container monitoring for docker image jrcs/letsencrypt-nginx-proxy-companion. re-installing 2.79-1.git6f01752.fc29 appears to have restored functionality. possibly the letsencrypt-nginx-proxy-companion is doing things it shouldn't, or is doing them the wrong way? SELinux is preventing docker-gen from 'connectto' accesses on the unix_stream_socket /run/docker.sock. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that docker-gen should be allowed connectto access on the docker.sock 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 'docker-gen' --raw | audit2allow -M my-dockergen # semodule -X 300 -i my-dockergen.pp Additional Information: Source Context system_u:system_r:container_t:s0:c472,c664 Target Context system_u:system_r:container_runtime_t:s0 Target Objects /run/docker.sock [ unix_stream_socket ] Source docker-gen Source Path docker-gen Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.2-47.fc29.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.20.3-200.fc29.x86_64 #1 SMP Thu Jan 17 15:19:35 UTC 2019 x86_64 x86_64 Alert Count 203 First Seen 2019-01-26 11:10:00 GMT Last Seen 2019-01-26 11:14:08 GMT Local ID e72454da-1518-4411-9030-28b764434c47 Raw Audit Messages type=AVC msg=audit(1548501248.243:996): avc: denied { connectto } for pid=3401 comm="docker-gen" path="/run/docker.sock" scontext=system_u:system_r:container_t:s0:c472,c664 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket permissive=0 Hash: docker-gen,container_t,container_runtime_t,unix_stream_socket,connectto Version-Release number of selected component: selinux-policy-3.14.2-47.fc29.noarch Additional info: component: selinux-policy reporter: libreport-2.9.7 hashmarkername: setroubleshoot kernel: 4.20.3-200.fc29.x86_64 type: libreport
This is not a bug, you are leaking the docker socket into a container, which allows the container to easily break out. If you are going to do this, you need to disable the SELinux protection on the container. SELinux is doing exactly what it is supposed to do. docker run -ti --security-opt label=disabled ...
Hi Dan, Thanks for stepping in and explaining. I've re-read a couple of your blog posts and found some articles on docker.sock security now :-) I might raise an issue at https://github.com/jwilder/nginx-proxy and https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion if i can reproduce it, but... i've "upgraded" from docker to moby-engine (and picked up container-selinux-2:2.80-1.git1b655d9.fc29 again as part of that) and the problem seems to have disappeared. /run/docker.sock is now system_u:object_r:container_var_run_t:s0 and restorecon doesn't appear to want to change that. Will keep checking. Thanks again!
Realize that moby-engine by default is not running containers with --selinux-enabled turned on . So this might be why this is working.
thanks again Dan, that explains it. I'm having a little trouble enabling it again but will comment on that in bug 1675125.
BTW You should be able to use buildah if you want to build containers inside of a container or podman if you want to execute container commands in a container, without having to leak in the docker socket.