[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242415#comment-16242415
]
Jason Lowe commented on YARN-7197:
----------------------------------
bq. Docker image can also be regulated through trusted docker registry. This
makes degree of difficulty to crack the system harder.
Agreed, if we can trust the images themselves aren't a source of nefarious
setup then we need to make sure the whitelist isn't abused to turn a trusted
image into an untrusted one.
Would it be too restrictive to enforce that a whitelist mount must have the
same path in the image as it does in the host? Then we can't have users
swapping out /etc for some custom directory. I looked briefly at the current
whitelist mount support and that appears to be how it works.
bq. I am starting to doubt the feasibility of blacklist approach to prevent
jailbreak or leak information at the cost of creating many bind mounted
location.
Totally agree, security is hard to get right. I don't see this as the only way
to prevent jailbreaks or leaks, rather just another tool in the admin's toolbox
to help make the whitelist easier to maintain if they have a case where they
want/need to whitelist something above another path that is sensitive. I would
expect many admins to never use it and instead be extremely selective in what
they whitelist, including many not whitelisting anything.
bq. We should accept the fact that privileged container is equal to root power
on the host system, hence only trusted users can be given access to spawn
privileged containers. We only govern the system by checking sudo privileges to
spawn privileged container, and honor file system ACL.
If we prevent the user from providing arbitrary images then I think we're close
to this, but as you pointed out if the user can bash an critical path in the
image with a bind mount then an unprivileged user could escalate within the
image (e.g.: smash suodoers file and image has sudo binary, smash /etc and
image has su binary, etc.). If the whitelist only allows bindmounts to the
same path as the host then I think we're OK here, but if it doesn't then we
need to address that.
bq. All bind mount path should not exceed the run command buffer.
We have to address that problem even with the current whitelist support. Filed
YARN-7455 to track that issue.
So to sum up, I agree this JIRA becomes simply a "nice to have" and not
necessary if whitelisted mounts cannot be retargeted within the image. I'm not
sure we have to close it as won't fix, since this could be a useful tool for
admins that know what they're doing. However I wouldn't see it as a must fix
for the next release either.
> 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: [email protected]
For additional commands, e-mail: [email protected]
