Bug 1656836

Summary: SELinux policy incomplete for Docker with user namespaces
Product: Red Hat Enterprise Linux 7 Reporter: Oliver Falk <ofalk>
Component: container-selinuxAssignee: Lokesh Mandvekar <lsm5>
Status: CLOSED ERRATA QA Contact: atomic-bugs <atomic-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.6CC: dornelas, dwalsh, lsu, lvrabec, mgrepl, mmalik, plautrba, ssekidde, vmojzis
Target Milestone: rcKeywords: Extras
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: container-selinux-2.78 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-23 17:40:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1186913    

Description Oliver Falk 2018-12-06 12:37:41 UTC
Description of problem:
When docker is configured to use user namespaces (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/getting_started_with_containers/index#user_namespaces_options) it stores the permanent  runtime files under /var/lib/docker/${usernamespaceuid}.${usernamespacegid}/* instead of just /var/lib/docker/*:
# ps -ef|grep userns-remap
root      6462     1  0 11:15 ?        00:00:26 /usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --default-runtime=docker-runc --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --userland-proxy-path=/usr/libexec/docker/docker-proxy-current --init-path=/usr/libexec/docker/docker-init-current --seccomp-profile=/etc/docker/seccomp.json --selinux-enabled --log-driver=journald --signature-verification=false --userns-remap=default --storage-driver overlay2 --add-registry registry.access.redhat.com
root     11203  3954  0 12:44 pts/0    00:00:00 grep --color=auto userns-remap

# find  /var/lib/docker/ -maxdepth 2
/var/lib/docker/
/var/lib/docker/100000.100000
/var/lib/docker/100000.100000/tmp
/var/lib/docker/100000.100000/containers
/var/lib/docker/100000.100000/plugins
/var/lib/docker/100000.100000/overlay2
/var/lib/docker/100000.100000/image
/var/lib/docker/100000.100000/volumes
/var/lib/docker/100000.100000/trust
/var/lib/docker/100000.100000/network
/var/lib/docker/100000.100000/swarm


Unfortunately, the standard SELinux policy (even with the container module applied) does not contain proper file labelling for this:
[root@rhel7 ~]# semodule -l|grep container
container	2.74.0
[root@rhel7 ~]# semanage fcontext -l|grep /var/lib/docker
/var/lib/docker(/.*)?                              all files          system_u:object_r:container_var_lib_t:s0 
/var/lib/docker/.*/config\.env                     all files          system_u:object_r:container_share_t:s0 
/var/lib/docker/vfs(/.*)?                          all files          system_u:object_r:container_file_t:s0 
/var/lib/docker/init(/.*)?                         all files          system_u:object_r:container_share_t:s0 
/var/lib/docker-latest(/.*)?                       all files          system_u:object_r:container_var_lib_t:s0 
/var/lib/docker/overlay(/.*)?                      all files          system_u:object_r:container_share_t:s0 
/var/lib/docker-latest/.*/config\.env              all files          system_u:object_r:container_share_t:s0 
/var/lib/docker/overlay2(/.*)?                     all files          system_u:object_r:container_share_t:s0 
/var/lib/docker-latest/init(/.*)?                  all files          system_u:object_r:container_share_t:s0 
/var/lib/docker/containers/.*/hosts                all files          system_u:object_r:container_share_t:s0 
/var/lib/docker/containers/.*/.*\.log              all files          system_u:object_r:container_log_t:s0 
/var/lib/docker/containers/.*/hostname             all files          system_u:object_r:container_share_t:s0 
/var/lib/docker-latest/overlay(/.*)?               all files          system_u:object_r:container_share_t:s0 
/var/lib/docker-latest/overlay2(/.*)?              all files          system_u:object_r:container_share_t:s0 
/var/lib/docker-latest/containers/.*/hosts         all files          system_u:object_r:container_share_t:s0 
/var/lib/docker-latest/containers/.*/.*\.log       all files          system_u:object_r:container_log_t:s0 
/var/lib/docker-latest/containers/.*/hostname      all files          system_u:object_r:container_share_t:s0 

As such, containers started with user namespaced docker are failing (some very simple container may work fine) with SELinux errors like the following:
# grep avc /var/log/audit/audit.log
type=AVC msg=audit(1544091055.262:306): avc:  denied  { read open } for  pid=6088 comm="bash" path="/etc/ld.so.cache" dev="dm-1" ino=38908586 scontext=system_u:system_r:container_t:s0:c176,c900 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1544091055.263:307): avc:  denied  { read open } for  pid=6088 comm="bash" path="/usr/lib64/libtinfo.so.5.9" dev="dm-1" ino=55117934 scontext=system_u:system_r:container_t:s0:c176,c900 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1544091055.263:308): avc:  denied  { read open } for  pid=6088 comm="bash" path="/usr/lib64/libtinfo.so.5.9" dev="dm-1" ino=55117934 scontext=system_u:system_r:container_t:s0:c176,c900 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=0

The list of commands which includes the proper labels into the policy:
# semanage fcontext -a -t container_var_lib_t '/var/lib/docker/[0-9]+\.[0-9]+(/.*)?'
# semanage fcontext -a -t container_share_t '/var/lib/docker/[0-9]+\.[0-9]+/.*/config\.env'
# semanage fcontext -a -t container_file_t '/var/lib/docker/[0-9]+\.[0-9]+/vfs(/.*)?'
# semanage fcontext -a -t container_share_t '/var/lib/docker/[0-9]+\.[0-9]+/init(/.*)?'
# semanage fcontext -a -t container_share_t '/var/lib/docker/[0-9]+\.[0-9]+/overlay(/.*)?'
# semanage fcontext -a -t container_share_t '/var/lib/docker/[0-9]+\.[0-9]+/overlay2(/.*)?'
# semanage fcontext -a -t container_share_t '/var/lib/docker/[0-9]+\.[0-9]+/containers/.*/hosts'
# semanage fcontext -a -t container_log_t '/var/lib/docker/[0-9]+\.[0-9]+/containers/.*/.*\.log'
# semanage fcontext -a -t container_share_t '/var/lib/docker/[0-9]+\.[0-9]+/containers/.*/hostname'


Version-Release number of selected component (if applicable): Docker on RHEL7.6


How reproducible: Always


Steps to Reproduce:
Follow instructions from here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/getting_started_with_containers/index#user_namespaces_options

Actual results:
Docker instance cannot be started due to SELinux violations.


Expected results:
Docker instance runs with user namespaces.


Additional info:
Customer case will be linked in a hurry.

Comment 2 Daniel Walsh 2019-01-10 20:13:24 UTC
You should try podman, it has much better user namespace support.

Fixed in container-selinux-2.78

Comment 5 Luwen Su 2019-04-13 15:45:30 UTC
# rpm -q docker container-selinux
docker-1.13.1-96.gitb2f74b2.el7.x86_64
container-selinux-2.95-2.el7_6.noarch

# docker run --rm -it rhel7 /bin/bash
Unable to find image 'rhel7:latest' locally
Trying to pull repository registry.access.redhat.com/rhel7 ... 
latest: Pulling from registry.access.redhat.com/rhel7
76608b6b9d54: Pull complete 
3c81a5d20855: Pull complete 
Digest: sha256:13586fd79ec345ad3ba6cb803e206b84ea9cf19bb9245d72b6913c8b40625a5c
Status: Downloaded newer image for registry.access.redhat.com/rhel7:latest
[root@d4279ba8142e /]# 


# ps -ef | grep /bin/bash
root      3709  3388  0 23:39 pts/0    00:00:00 /usr/bin/docker-current run --rm -it rhel7 /bin/bash
808080    3908  3891  0 23:40 pts/1    00:00:00 /bin/bash
root      4221  4185  0 23:44 pts/2    00:00:00 grep --color=auto /bin/bash

Comment 7 errata-xmlrpc 2019-04-23 17:40:07 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0861

Comment 8 Red Hat Bugzilla 2023-09-14 04:43:27 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days