hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Badger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-5534) Allow whitelisted volume mounts
Date Tue, 18 Jul 2017 15:56:00 GMT

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

Eric Badger commented on YARN-5534:
-----------------------------------

bq. The admin will define a comma separated list of <src>:<mode> (ro or rw) mounts,
the requesting user will supply <src>:<dest>:<mode> - mode must be equal
to or lesser than the admin defined mode (i.e. admin defines mount as rw, user can bind mount
as rw OR ro).

I'm not sure I understand this correctly. Let me know if I have this right. So you're proposing
having a whitelist of volumes that can be bind-mounted that is defined by the NM and then
have the user supply a list of volumes that need to be a subset of that whitelist? What about
volumes that the NM always wants to mount regardless of the user? 

bq. One question here, does any feel there is value in allowing the admin to restrict the
destination mount point within the container?
Well they could certainly shoot themselves in the foot pretty easily by mounting over an important
directory within the image (e.g. /bin), but I'm not sure if that will ever lead to anything
that could prove malicious. Maybe a possibility is that they overwrite /bin with their mount
that has a bunch of crafted malicious binaries. Though I'm not sure how they would get the
malicious binaries in the src volume on the node. And also, I'm not sure if this is anything
different/worse than putting a setuid binary in the distributed cache. Or another possibility
would be overwriting glibc with a malicious version. Basically allowing arbitrary mount points
allows the user to overwrite things owned by root, which makes me a little uneasy. My question
is whether they can leverage these mount points to gain root in the container if minimal capabilities
(aka not SETUID/SETGID/etc.) are given. 

> Allow whitelisted volume mounts 
> --------------------------------
>
>                 Key: YARN-5534
>                 URL: https://issues.apache.org/jira/browse/YARN-5534
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>            Reporter: luhuichun
>            Assignee: Shane Kumpf
>         Attachments: YARN-5534.001.patch, YARN-5534.002.patch
>
>
> Introduction 
> Mounting files or directories from the host is one way of passing configuration and other
information into a docker container. 
> We could allow the user to set a list of mounts in the environment of ContainerLaunchContext
(e.g. /dir1:/targetdir1,/dir2:/targetdir2). 
> These would be mounted read-only to the specified target locations. This has been resolved
in YARN-4595
> 2.Problem Definition
> Bug mounting arbitrary volumes into a Docker container can be a security risk.
> 3.Possible solutions
> one approach to provide safe mounts is to allow the cluster administrator to configure
a set of parent directories as white list mounting directories.
>  Add a property named yarn.nodemanager.volume-mounts.white-list, when container executor
do mount checking, only the allowed directories or sub-directories can be mounted. 



--
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