[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240765#comment-16240765
]
Jason Lowe commented on YARN-7197:
----------------------------------
bq. Even if it worked, we could be leaking private container information to
outside. For example, if someone mount a random number generator socket for
encryption seed, and admin blacklisted random number generator from mounting.
The result all end up with 0s. There is no one know about a mistake have been
made. It could have serious consequence to security.
Couldn't the same be said about directories? If the admin blacklists /var/run
but whitelists /var or blacklists /dev/pts but allows /dev there can be
problems. The admin needs to understand the ramifications of what they are
whitelisting and blacklisting with respect to what the container needs to
function properly.
The current patch allows users to mount above blacklisted paths and still
access them which I think we all agree defeats the point of the blacklist and
isn't what an admin would expect when configuring the blacklist. Bottom line
is either we need to try to blot out the blacklisted paths when the user mounts
above it regardless of path type or we don't allow admins to blacklist paths
that aren't directories on the host.
I'm OK if we want to go with the latter as long as we document that blacklisted
paths that are not directories on the host do not work as expected in practice.
We can consider adding the support later to remove that restriction. In any
case, I think the patch needs to behave like the following:
# If a blacklisted path or a path under the blacklisted path attempts to be
mounted the container should just fail with an error message stating the
requested path is blacklisted.
# If a whitelisted requested mount is a prefix of any of the blacklisted paths
then the blacklisted path needs a bind-mount to prevent access to the
blacklisted path under the requested mount.
bq. bind_mount is type-bind,source=, target=, and readonly and two %s
Ah sorry, my apologies. I completely missed that bind_mount wasn't a path as
the variable name implied but actually the format string for sprintf. This
should be passed to sprintf as the format string rather than duplicating it,
otherwise someone is going to come along and update one without updating the
other. The overrun potential with tmp_buffer (as opposed to tmp_buffer_2) is
still a concern.
> 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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
