[ 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