[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225812#comment-16225812
]
Jason Lowe commented on YARN-7197:
----------------------------------
Solution 3 is more secure since the paths are unavailable within the container.
Even if there is a trojan in the container that escalates privilege, the
hacker needs to break outside of the container to access the path rather than
accessing it within the container directly.
bq. The third solution can throw people off, if they do not know about
black-list is hijacked to empty location.
I'm not sure how admins are going to be confused or upset that paths in the
blacklist were not what was expected. Either it shouldn't be accessed and thus
shouldn't matter what's there or it needs to be there and shouldn't be in the
blacklist. Or am I missing a scenario where there's an in-between?
IMHO it's more confusing to users if the blacklist doesn't actually prevent
access to the blacklisted paths. The point of the blacklist is that containers
should not be able to access those paths on the host.
bq. Mounting from parent of black list directory will depends on filesystem acl
to enforce the permission.
If we are simply relying on filesystem ACLs to cover us if the user mounts
above the blacklist then I would argue there's no point to the blacklist.
Either we trust the filesystem ACLs or we don't. If we don't then letting the
admin trivially configure a setup where the user can mount above the blacklist
path is not helpful or intuitive.
If we are serious about not trusting the filesystem ACLs from within the
container (i.e.: actually need a blacklist) then we need to do whatever we can
to prevent access even if the admins (un)intentionally configure paths above
the blacklisted path. That means we need to do something like Solution 3 above
or fail to create the container when the user mounts above. Choosing to fail
the container means we're essentially at Solution 1 where the admin has no
ability to cherry-pick out paths that should not be allowed and must maintain
explicit paths to things that are allowed. Then the blacklist would have no
utility short of documentation of what normally should not be placed in the
whitelist.
> 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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
