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-7197) Add support for a volume blacklist for docker containers
Date Tue, 24 Oct 2017 20:59:00 GMT

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

Eric Badger commented on YARN-7197:
-----------------------------------

[~eyang]

bq. Symlink are banned to prevent mistakes. I can lift the symlink check and trust that system
admin will always express physical path correctly instead of symlink paths in black list
I think that if we're going to allow symlinks in the whitelist case then we should allow them
here as well. Also, allowing symlinks in the white/black lists can be useful. For example,
if you have /hadoop symlinked to the most recent hadoop version, maybe you want to add that
to the whitelist, but you don't want to change the whitelist everytime you update your hadoop
version. 

{quote}
I did not separate black list for read-only and read-write to reduce wordy configurations
that could generate security holes. For example, if someone would like to mount /run as read
only, and allow docket.socket to be used inside container.
Should they specify?
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed-read-only:/run/docker.socket
black-listed-read-write: /run
Or?
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed-read-only: /run/docker.socket
Ideally, user should be able to specify the minimum to get the system to work:
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
or
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed: /var/run
{quote}
Even with the blacklist split up into ro and rw, why wouldn't they be able to simply add what
they want to the whitelist and not bother with the blacklist? Splitting the blacklist gives
you more fine-grained control over exactly what you want to disallow. For example, if you
had a directory where you wanted to be able to mount almost everything as rw, except for a
few things. Then you'd whitelist the whole directory as rw and use the blacklist to disallow
the specific directories as ro/rw. Maybe you have a keytab under one of those directories
that you need to disallow rw access and you have a conf directory that you only want to be
read, not written. If you don't split up the blacklist then you would lose the ro/rw control
on those files and they would have to be either all or nothing.

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