Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1222060 - SELinux blocking volume Mounts
Summary: SELinux blocking volume Mounts
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Atomic
Classification: Retired
Component: kernel
Version: unspecified
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Colin Walters
QA Contact:
URL:
Whiteboard:
Depends On: 1165982 1193590 1214810 1227096
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-15 16:04 UTC by Jay Vyas
Modified: 2015-10-28 14:30 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1214810
Environment:
Last Closed: 2015-10-28 14:30:25 UTC
RHEL 7.3 requirements from Atomic Host:
Embargoed:

Attachments (Terms of Use)

Description Jay Vyas 2015-05-15 16:04:42 UTC 
In general, people need an easy way to run kubernetes apps with host mounts.

This bug effects Red Hat Atomic 7.1.3

To reproduce, 

(1) enable selinux and 


(2) try to run any kubernetes app which mounts a external volume

OR 

Run the kubernetes e2e tests, where we have a pending reproducer for this https://github.com/GoogleCloudPlatform/kubernetes/pull/8254.  

The output we get from these tests:

  Expected error:
      <*errors.errorString | 0xc20825aef0>: {
          s: "pod pod-b4623a77-fb1a-11e4-8c06-ecf4bbc72674 terminated with failure: &{ExitCode:1 Signal:0 Reason: Message: StartedAt:2015-05-15 11:54:45 -0400 EDT FinishedAt:2015-05-15 11:54:45 -0400 EDT Contain
erID:docker://bee5e651dd1ecd1346e53afe8bd293555dd2af55ca174caea6b3e860b4d72df4}",
      }
      pod pod-b4623a77-fb1a-11e4-8c06-ecf4bbc72674 terminated with failure: &{ExitCode:1 Signal:0 Reason: Message: StartedAt:2015-05-15 11:54:45 -0400 EDT FinishedAt:2015-05-15 11:54:45 -0400 EDT ContainerID:doc
ker://bee5e651dd1ecd1346e53afe8bd293555dd2af55ca174caea6b3e860b4d72df4}
  not to have occurred
Comment 1 Steve Watt 2015-05-15 16:24:58 UTC 
To add to this. The Kubernetes hostPath volume is the method to access local storage from a container on RHEL Atomic. It is really important that we get this working with SELinux enabled. 

As a simple unit test, I suspect that there is likely an issue with just 

docker run -v /some/content:/usr/share/nginx/html -d nginx

The container should start but you'll get permission denied if you try and curl a webpage from the mounted directory.
Comment 2 Daniel Walsh 2015-05-15 17:52:11 UTC 
docker run -v /some/content:/usr/share/nginx/html:Z -d nginx

Would do the right thing and relabel /some/content.  (Not merged upstream yet).

If k8s supports RO/RW switch we should add Private/Shared switch.
Comment 3 Jay Vyas 2015-05-18 14:16:19 UTC 
Great unit test idea ! Steve is right... Thats a simple way to test - 

-bash-4.2# touch /tmp/index.html

-bash-4.2# docker run -v /tmp:/usr/share/nginx/html -p 8001:80 -d nginx                                                                                                                                            
418886f1c83877d40cd9cd25b2c01d13ac037d4be4c2e34f4bd57bdaf12b7b8a
-bash-4.2# curl localhost:8001/index.html
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.7.12</center>
</body>
</html>
-bash-4.2# curl localhost:8002/index.html                                                                                                                                                                          
curl: (7) Failed connect to localhost:8002; Connection refused
-bash-4.2# curl localhost:8001/index.html
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.7.12</center>
</body>
</html>
-bash-4.2# getenforce 
Enforcing
-bash-4.2# setenforce 0
-bash-4.2# curl localhost:8001/index.html
Comment 4 Paul Morie 2015-05-19 16:52:11 UTC 
Dan, it's not clear to me what the :Z opt on the bind does.
Comment 5 Paul Morie 2015-05-19 16:55:37 UTC 
Also, all, FYI: https://github.com/GoogleCloudPlatform/kubernetes/issues/7925
Comment 6 Paul Morie 2015-05-19 17:14:39 UTC 
TL;DR recap of my phone convo w/ Tim SC:

There is no treatment for selinux wrt hostDir plugin.  Eventually, the security work going on now will ensure that the selinux context is relabeled so that it plays nice with the selinux context a container is running in.

For now, I would look at whether the policy changed around /var/lib/kubelet during 7.1.1 -> present.
Comment 7 Daniel Walsh 2015-05-20 12:25:03 UTC 
Z (private) option causes docker daemon do:

chcon -R -t svirt_sandbox_file_t -l MCSLEVEL /some/content

Basically it labels the content under /some/content with a label that the process labels inside the container can read/write.


Lower case z changes the label to something all containers can use.  (Shared)
Comment 10 Jan Safranek 2015-05-28 14:52:03 UTC 
Looking at Atomic Host 7.1.2, docker already understands :z and :Z options in -v argument, so what we really need to do is to pass this option from Kubernetes.

Still, how should it work? Random user posts new pod with say "hostDir: path: /etc". Kubernetes+docker should probably not relabel whole /etc on the host (!) to svirt_sandbox_file_t. There must be some policy.

For the time being, I would emphasize in our documentation that the system admin is responsible for manually labeling the directories that should be shared with pods.
Comment 11 Daniel Walsh 2015-05-28 14:55:54 UTC 
Right there should be some indication whether the direcory is Shared or Private to the POD.  Doesn't K8s handle this someway with R/O versus R/W?

THe z/Z patch prevents relabeling of /etc, /usr and /, but that is just a quick hack to stop the easiest stumbled upon problem.  I think if the person building the app does not specify type of shareing, then we do nothing.  And let SELinux block the access if necessary.

There is no real easy way to do this.  Either the user or the k8s has someway to know whether the content is private to the pod or not.
Comment 12 Daniel Walsh 2015-05-28 14:56:23 UTC 
BTW this just got merged to docker-1.7 yesterday, So all docker should grow this ability now.
Comment 13 Jan Safranek 2015-05-28 15:33:31 UTC 
(In reply to Daniel Walsh from comment #11)
> Right there should be some indication whether the direcory is Shared or
> Private to the POD.  Doesn't K8s handle this someway with R/O versus R/W?

Yes, there is RO/RW flag, we need to add Shared/Private flag (:z/:Z).

> THe z/Z patch prevents relabeling of /etc, /usr and /, but that is just a
> quick hack to stop the easiest stumbled upon problem.  I think if the person
> building the app does not specify type of shareing, then we do nothing.  And
> let SELinux block the access if necessary.

Ok, so all we need to do in Kubernetes is to add :z/:Z to hostDir mounts and Docker will re-label only the safe parts, right? Even when using upstream Docker?
Comment 14 Daniel Walsh 2015-05-28 15:38:18 UTC 
When docker-1.7 ships, which is supposed to happen mid June.

Safe Parts?  It will relabel the Src directory if told to relabel it, but will fail if you pass in /etc, /usr or /.  It would gladly relabel subdirs though.

/usr/lib for example.
Comment 15 Daniel Walsh 2015-10-28 14:30:25 UTC 
Fixed in docker-1.7

With :z and :Z support.
Note You need to log in before you can comment on or make changes to this bug.