[
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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
