hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (YARN-7197) Add support for a volume blacklist for docker containers
Date Tue, 07 Nov 2017 18:03:00 GMT

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

Eric Yang edited comment on YARN-7197 at 11/7/17 6:03 PM:
----------------------------------------------------------

[~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 in white list.

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.


was (Author: eyang):
[~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


Mime
View raw message