Bug 1412340 - docker should check for correct selinux contexts on custom graph locations
Summary: docker should check for correct selinux contexts on custom graph locations
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard: aos-scalability-35
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-11 19:46 UTC by Jeremy Eder
Modified: 2019-03-06 01:01 UTC (History)
3 users (show)

Fixed In Version: vgoyal@redhat.com, dwalsh@redhat.com, caiqian@redhat.com
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-11 20:01:09 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jeremy Eder 2017-01-11 19:46:30 UTC
Description of problem:

In the context of testing overlay2 on RHEL7.4, we found that the policy in container-selinux is:

# cat container-selinux/container.fc
/var/lib/docker/overlay(/.*)?   gen_context(system_u:object_r:container_share_t,s0)
/var/lib/docker/overlay2(/.*)?  gen_context(system_u:object_r:container_share_t,s0)

This handles the default location in RHEL but does not account for alternate locations configurable in /etc/sysconfig/docker-storage:

DOCKER_STORAGE_OPTIONS=-s overlay2 -g /overlay

I have not looked at what's happening in rawhide as far as partitioning goes, nor what atomic looks like, but I believe we need a solution to this for all 3.  Perhaps the check belongs in docker itself?

I was seeing errors like this:
root@dhcp23-87: ~ # docker run -it rhel7 date
date: error while loading shared libraries: libc.so.6: cannot open shared object file: Permission denied
root@dhcp23-87: ~ # tail /var/log/audit/audit.log|grep deni
type=AVC msg=audit(1484151049.780:238): avc:  denied  { read open } for  pid=3284 comm="date" path="/etc/ld.so.cache" dev="vda3" ino=537075869 scontext=system_u:system_r:svirt_lxc_net_t:s0:c402,c575 tcontext=system_u:object_r:default_t:s0 tclass=file
type=AVC msg=audit(1484151049.780:239): avc:  denied  { read open } for  pid=3284 comm="date" path="/usr/lib64/libc-2.17.so" dev="vda3" ino=469765886 scontext=system_u:system_r:svirt_lxc_net_t:s0:c402,c575 tcontext=system_u:object_r:default_t:s0 tclass=file
type=AVC msg=audit(1484151049.780:240): avc:  denied  { read open } for  pid=3284 comm="date" path="/usr/lib64/libc-2.17.so" dev="vda3" ino=469765886 scontext=system_u:system_r:svirt_lxc_net_t:s0:c402,c575 tcontext=system_u:object_r:default_t:s0 tclass=file

The fix for me was:
# chcon -t docker_share_t -R /overlay*

Comment 1 Daniel Walsh 2017-01-11 20:01:09 UTC
This has always been a problem with SELinux, if the admin changes the default location of the content, it is up to him to fix the SELinux labels.

# semanage fcontext -a -e /var/lib/docker/overlay /overlay
# restorecon -R -v /overlay

Would fix the issue.

You would have the exact same issue if you changed the httpd root from /var/lib/wwww to /www.  

I afraid their is no way to fix this.

Comment 2 Jeremy Eder 2017-01-11 20:02:31 UTC
There is a way to detect and throw a useful error though.

Comment 3 Daniel Walsh 2017-01-11 21:07:45 UTC
Not really, there is no good way for a tool to figure out why it got permission denied.  Could have been DAC, MAC, Namespaces ...

Comment 4 Jeremy Eder 2017-01-12 11:57:14 UTC
Verify that the top-level graph directory has docker_share_t ?

Comment 5 Daniel Walsh 2017-01-12 13:42:42 UTC
docker daemon has no idea what the label of any particular directory should be.  It could ask SELinux what the label should be, but SELinux would not know unless the distribution or an admin told it.  If docker asked the SELinux kernel what the label of /overlay should be, the kernel would tell it, default_t.


# matchpathcon -m dir /overlay
/overlay	system_u:object_r:default_t:s0

Now if you tell SELinux about it.

# semanage fcontext -a -e /var/lib/docker/overlay /overlay
# matchpathcon -m dir /overlay
/overlay	system_u:object_r:container_share_t:s0

We really frown on people hard coding file context types into code. since this prevents other people from using other policy like MLS.  Also we have changed the policy in the past for example going from svirt_lxc_net_t -> container_file_t.


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