Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 7 Nov 2017 18:02:00 +0000 (UTC)
From: "Eric Yang (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.13102363.1505418463000.172327.1510077720840@Atlassian.JIRA>
In-Reply-To: <JIRA.13102363.1505418463000@Atlassian.JIRA>
References: <JIRA.13102363.1505418463000@Atlassian.JIRA> <JIRA.13102363.1505418463901@jira-lw-us.apache.org>
Subject: [jira] [Commented] (YARN-7197) Add support for a volume blacklist
 for docker containers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 07 Nov 2017 18:02:06 -0000


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

Eric Yang commented on YARN-7197:
---------------------------------

[~jlowe] {quote}
 If the whitelist only allows bindmounts to the same path as the host then I think we're OK here, but if it doesn't then we need to address that.
{quote}

Most of the docker image is not a full Linux image.  It is possible that system admin provide ability to mount /etc/hadoop/conf to a path of image chosen directory to read hadoop configuration.  It would be better for us to support mapping of different source to destination path.

If someone mounted {{/etc/shadow}}, {{/etc/passwd}}, {{/etc/group}} and {{/etc/sudoers}} from their user home directory into container for privileges escalation.  They still need to defeat the following:

#  Add sudo binary into the container image.
#  Find a way to remove {{--cap-drop=ALL}} which we hard coded into container-executor.
#  Gain write access to outside world through a mounted location like HDFS.

Trusted registry protects 1.  Container-executor binary protects 2.  Allowed white list protects 3.  I think it's difficult to get a privilege escalation, if the protections are in place.  The original intend to protect QA users from destroying cluster hosts and giving them access to spawn root container is a noble cause.  However, I don't think we will find a right way to protect root from root using black list.  {{--cap-drop=ALL}} is the better way to give them container root power and keep that access within the container.  I will leave this JIRA open for others to try.

> Add support for a volume blacklist for docker containers
> --------------------------------------------------------
>
>                 Key: YARN-7197
>                 URL: https://issues.apache.org/jira/browse/YARN-7197
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>            Reporter: Shane Kumpf
>            Assignee: Eric Yang
>         Attachments: YARN-7197.001.patch, YARN-7197.002.patch, YARN-7197.003.patch, YARN-7197.004.patch, YARN-7197.005.patch
>
>
> Docker supports bind mounting host directories into containers. Work is underway to allow admins to configure a whilelist of volume mounts. While this is a much needed and useful feature, it opens the door for misconfiguration that may lead to users being able to compromise or crash the system. 
> One example would be allowing users to mount /run from a host running systemd, and then running systemd in that container, rendering the host mostly unusable.
> This issue is to add support for a default blacklist. The default blacklist would be where we put files and directories that if mounted into a container, are likely to have negative consequences. Users are encouraged not to remove items from the default blacklist, but may do so if necessary.


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

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