[ 
https://issues.apache.org/jira/browse/YARN-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317178#comment-16317178
 ] 

Eric Badger commented on YARN-7516:
-----------------------------------

Hey [~eyang], thanks for the updated patch!

{noformat}
+  char **trusted_repo = 
get_configuration_values_delimiter("docker.trusted.registries", 
CONTAINER_EXECUTOR_CFG_DOCKER_SECTION, conf, ",");
{noformat}
Minor nit: the variable and config value aren't consistent (repo vs. registry)

{noformat}
+      for (i = 0; trusted_repo[i] != NULL; i++) {
+        if (strncmp(image_name, trusted_repo[i], strlen(trusted_repo[i]))==0) {
+          fprintf(ERRORFILE, "image: %s is trusted in %s.\n", image_name, 
trusted_repo[i]);
+          found=true;
+        }
+      }
{noformat}
Once we find the image, we can break out of the loop. No need to continue 
through the rest of the array.

{noformat}
+        if (strncmp(image_name, trusted_repo[i], strlen(trusted_repo[i]))==0) {
{noformat}
I'm far from a web url expert, so this may be obviously impossible, but I'm 
wondering if the following case could be exploited with this: 
The trusted registry is a.b.c and some malicious domain gets a.b.c.d. Since we 
are doing a strncmp only on the length of the trusted repo, then we would allow 
a.b.c.d 

{noformat}
+| `docker.trusted.registries` | Comma separated list of trusted docker 
registries for running trusted privileged docker containers.  By default, no 
registries are defined. |
{noformat}
I'm having a hard time coming to this definition of "trusted". In my mind, I 
could trust a registry without wanting to allow privileged containers. For me, 
trusting a registry means that I will allow containers from it to run at all. 
Then the next step would be allowing them to run with privileges. Possibly this 
doesn't all need to happen in this JIRA, but I'm hesitant to use the word 
"trusted", since I think that there are different levels of trust going on 
here. 

> Security check for untrusted docker image
> -----------------------------------------
>
>                 Key: YARN-7516
>                 URL: https://issues.apache.org/jira/browse/YARN-7516
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>         Attachments: YARN-7516.001.patch, YARN-7516.002.patch, 
> YARN-7516.003.patch, YARN-7516.004.patch, YARN-7516.005.patch
>
>
> Hadoop YARN Services can support using private docker registry image or 
> docker image from docker hub.  In current implementation, Hadoop security is 
> enforced through username and group membership, and enforce uid:gid 
> consistency in docker container and distributed file system.  There is cloud 
> use case for having ability to run untrusted docker image on the same cluster 
> for testing.  
> The basic requirement for untrusted container is to ensure all kernel and 
> root privileges are dropped, and there is no interaction with distributed 
> file system to avoid contamination.  We can probably enforce detection of 
> untrusted docker image by checking the following:
> # If docker image is from public docker hub repository, the container is 
> automatically flagged as insecure, and disk volume mount are disabled 
> automatically, and drop all kernel capabilities.
> # If docker image is from private repository in docker hub, and there is a 
> white list to allow the private repository, disk volume mount is allowed, 
> kernel capabilities follows the allowed list.
> # If docker image is from private trusted registry with image name like 
> "private.registry.local:5000/centos", and white list allows this private 
> trusted repository.  Disk volume mount is allowed, kernel capabilities 
> follows the allowed list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to