[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240946#comment-16240946
]
Eric Yang commented on YARN-7197:
---------------------------------
{quote}
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.
{quote}
I see that I missed a key point about mounting above parent directory. When
the target location is set to another location, the blacklist addictive does
not enforce blacklisted path relative to target location. I will make
refinement for this point.
In general, user might get a read-only black listed directory when mount point
are covering large span of paths. If they encounter the error message, they
are likely to ask system admin about the black listed path. They can refine
mount points accordingly. Hackers will try both explicit defined mount or
implicit defined mounts to dodge security. They should not get through using
either source=target path, or source=~target attempts. If this is implemented
accordingly, empty file or socket type are probably lesser concern because
target location usually don't exist.
Do you agree that by tracking blacklisted path relative location to target
location, we can satisfy the original motive of preventing jail break out of
container?
> 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
