http://bugzilla.opensuse.org/show_bug.cgi?id=1186158 G.M. Venekamp changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|SElinux is blocking socket |SElinux is blocking podman |access for |socket access to |/var/run/podman/podman.sock |/var/run/podman/podman.sock -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1186158 http://bugzilla.opensuse.org/show_bug.cgi?id=1186158#c1 --- Comment #1 from G.M. Venekamp --- Running containers like traefik fail on MicroOS due to SELinux. I am running: # head -2 /etc/os-release NAME="openSUSE MicroOS" # VERSION="20210520" as of this morning and I am seeing the following selinux denied in /var/log/audit/audit.log type=AVC msg=audit(1621669323.589:1091): avc: denied { read write } for pid=4872 comm="entrypoint.sh" path="/dev/null" dev="tmpfs" ino=5 scontext=system_u: system_r:container_t:s0:c587,c659 tcontext=system_u:object_r:container_file_t:s0:c587,c659 tclass=chr_file permissive=1 type=AVC msg=audit(1621669323.593:1092): avc: denied { open } for pid=4872 comm="entrypoint.sh" path="/dev/null" dev="tmpfs" ino=5 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:object_r:container_file_t:s0:c587,c659 tclass=chr_file permissive=1 type=AVC msg=audit(1621669323.613:1093): avc: denied { read } for pid=4885 comm="traefik" name="hpage_pmd_size" dev="sysfs" ino=3207 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=1 type=AVC msg=audit(1621669323.613:1094): avc: denied { open } for pid=4885 comm="traefik" path="/sys/kernel/mm/transparent_hugepage/hpage_pmd_size" dev="sysfs" ino=3207 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=1 type=AVC msg=audit(1621669323.701:1095): avc: denied { create } for pid=4885 comm="traefik" scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=netlink_route_socket permissive=1 type=AVC msg=audit(1621669323.701:1096): avc: denied { bind } for pid=4885 comm="traefik" scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=netlink_route_socket permissive=1 type=AVC msg=audit(1621669323.701:1097): avc: denied { nlmsg_read } for pid=4885 comm="traefik" scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=netlink_route_socket permissive=1 type=AVC msg=audit(1621669323.701:1098): avc: denied { getattr } for pid=4885 comm="traefik" scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=netlink_route_socket permissive=1 type=AVC msg=audit(1621669323.777:1099): avc: denied { create } for pid=4872 comm="traefik" scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=tcp_socket permissive=1 type=AVC msg=audit(1621669323.777:1100): avc: denied { setopt } for pid=4872 comm="traefik" scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=tcp_socket permissive=1 type=AVC msg=audit(1621669323.777:1101): avc: denied { bind } for pid=4872 comm="traefik" scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=tcp_socket permissive=1 type=AVC msg=audit(1621669323.777:1102): avc: denied { node_bind } for pid=4872 comm="traefik" saddr=::1 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:object_r:node_t:s0 tclass=tcp_socket permissive=1 type=AVC msg=audit(1621669323.777:1103): avc: denied { name_bind } for pid=4872 comm="traefik" src=80 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=1 type=AVC msg=audit(1621669323.777:1104): avc: denied { net_bind_service } for pid=4872 comm="traefik" capability=10 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=capability permissive=1 type=AVC msg=audit(1621669323.777:1105): avc: denied { listen } for pid=4872 comm="traefik" lport=80 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=tcp_socket permissive=1 type=AVC msg=audit(1621669323.777:1106): avc: denied { getattr } for pid=4872 comm="traefik" lport=80 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=tcp_socket permissive=1 type=AVC msg=audit(1621669323.777:1107): avc: denied { accept } for pid=4872 comm="traefik" lport=443 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:container_t:s0:c587,c659 tclass=tcp_socket permissive=1 type=AVC msg=audit(1621669323.781:1108): avc: denied { watch } for pid=4872 comm="traefik" path="/etc/traefik" dev="overlay" ino=93 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=unconfined_u:object_r:etc_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1621669323.781:1109): avc: denied { write } for pid=4872 comm="traefik" name="podman.sock" dev="tmpfs" ino=1239 scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=1 type=AVC msg=audit(1621669323.781:1110): avc: denied { connectto } for pid=4872 comm="traefik" path="/run/podman/podman.sock" scontext=system_u:system_r:container_t:s0:c587,c659 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 type=SERVICE_START msg=audit(1621669323.805:1111): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=podman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1186158 http://bugzilla.opensuse.org/show_bug.cgi?id=1186158#c3 --- Comment #3 from Thorsten Kukuk --- (In reply to G.M. Venekamp from comment #2)

Using podman 3.2.0 and starting the docker API as a regular user, i.e. systemctl --user start podman yield the same issues that SELinux forbids reading /run/user/1000/podman/podman.sock The socket is readable from outside a container, but from the inside SELinux is preventing access to it.

That's exatlx what SELinux should do and is designed for, so everything is working. Accessing the podman.sock from inside a container is really dangerous security wise. If you really need that, you need to learn SELinux and adjust the policy for your use case (or look if somebody has already a solution documented somewhere). But we will not allow this by default. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1186158 http://bugzilla.opensuse.org/show_bug.cgi?id=1186158#c5 --- Comment #5 from G.M. Venekamp --- On second thought I might not agree. I would agree if I expose a root owned podman.sock to a rootless container. I am not doing that. When I start podman like so: systemctl --user start podman, and thus I am creating a socket under /run/user/<uid>/podman/podman.sock. This socket is owned by the unprivileged user. Also this socket would not gain access to root owned containers. As far as I understand, rootless and rootfull are separated with podman. Therefore I would argue that the scope of the security is limited to that of an ordinary user. Hence it would be okay to expose the podman.sock to containers owned to that same user. Inside a rootless container, I would not be able to gain any elevation or anything otherwise. Inside a rootless container I cannot do more then on the outside. Therefore SELinux should not block read access. I don't think you ever write to the docker API and blocking write access would make sense. Is my reasoning flawed in any way and if so, how? -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1186158 http://bugzilla.opensuse.org/show_bug.cgi?id=1186158#c10 --- Comment #10 from G.M. Venekamp --- I'll try to replicate the issue in a clean VM and report back. Might be the case that the SELinux rules have been altered, such that this issues has been mitigated already. -- You are receiving this mail because: You are the assignee for the bug.