[jira] [Comment Edited] (YARN-7197) Add support for a volume blacklist for docker containers

["Eric Yang (JIRA)" <ji...@apache.org>]

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

Eric Yang edited comment on YARN-7197 at 10/24/17 8:32 PM:
-----------------------------------------------------------

[~ebadger] 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 found myself expressing /var/run/utmp more often instead of /run/utmp, and double negative could slip through undetected when symlinks are supported for black list.

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?

{code}
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed-read-only:/run/docker.socket
black-listed-read-write: /run
{code}

Or?

{code}
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed-read-only: /run/docker.socket
{code}

Ideally, user should be able to specify the minimum to get the system to work:

{code}
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
{code}

or

{code}
white-listed-read-only: /run
black-listed-read-only: /run/docker.socket
{code}

Blacklist might be a secret list for paranoid system admin.  This is the reason that we reveal as little information as possible about the black list.


was (Author: eyang):
[~ebadger] 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 found myself expressing /var/run/utmp more often instead of /run/utmp, and double negative could slip through undetected when symlinks are supported for black list.

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?

{code}
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed-read-only:/run/docker.socket
black-listed-read-write: /run
{code}

Or?

{code}
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed-read-only:/run/docker.socket
{code}

Ideally, user should be able to specify the minimum to get the system to work:

{code}
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
{code}

or

{code}
white-listed-read-only: /run
black-listed-read-only: /run/docker.socket
{code}


> 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