hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7197) Add support for a volume blacklist for docker containers
Date Mon, 06 Nov 2017 19:39:00 GMT

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


Mime
View raw message