Bug 1656836 - SELinux policy incomplete for Docker with user namespaces [NEEDINFO]
Summary: SELinux policy incomplete for Docker with user namespaces
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: container-selinux
Version: 7.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Lokesh Mandvekar
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1186913
TreeView+ depends on / blocked
 
Reported: 2018-12-06 12:37 UTC by Oliver Falk
Modified: 2019-04-23 17:40 UTC (History)
9 users (show)

Fixed In Version: container-selinux-2.78
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-23 17:40:07 UTC
Target Upstream Version:
ofalk: needinfo? (dwalsh)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0861 None None None 2019-04-23 17:40:12 UTC

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


Note You need to log in before you can comment on or make changes to this bug.